RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)

[Miloslav Trmač]

i.grok at 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