i.grok@comcast.net 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