i.grok@xxxxxxxxxxx pÃÅe v Ãt 21. 12. 2010 v 18:52 -0500: > On Tue, Dec 21, 2010 at 10:37:44PM +0100, Miloslav TrmaÄ wrote devel: > > Colin Walters pÃÅe v Ãt 21. 12. 2010 v 11:47 -0500: > > > "But they still have uid 0, which typical system installation allows > > > root to do things. For example, /bin/sh is 0755 and /bin is also 0755 > > > perms. A disarmed root process can still trojan a system. But what if > > > we got rid of all the read/write permissions for root?" > > > > > > So...right, "we can do these small changes, and then if we do this BIG > > > CHANGE, it all works!". But this feature doesn't include BIG CHANGE, > > > and there are no plans to, right? > > No. The original plans didn't count with the fact that changing > > permissions by owner does not require any capabilities either. > > > > If an attacker were controlling a process running with uid 0 and no > > capabilities at all, and /bin/sh were 0555, nothing prevents the > > attacker from chmod()ing /bin/sh to 0755 and overwriting it. This makes > > any attempts to change the file permissions rather pointless. > > Ok, so who says that the files must be owned by root? Make them owned by > some other user -- say, bin? (or does that have another use that my > google search isn't coming up with?) This is possible, but it would be a much larger change to the system. To take a particular example, look at /etc/shadow. It needs to be protected against attackers, so it should not be owned by root - let's make it owned by "adm", say. On the other hand, passwd(1) should be able to modify it, so passwd(1) should be set-uid "adm", not "root". On the other hand, PAM pretty strongly assumes that is is running as root - it is full of setuid() and other system calls that are root-only, and arbitrary PAM modules may, and often do, assume that they are running as root, therefore passwd(1) should be set-uid "root". See the problem? Mirek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
