Re: RFC: disablenetwork facility. (v4)

[Serge E. Hallyn]

Quoting Valdis.Kletnieks@xxxxxx (Valdis.Kletnieks@xxxxxx):
> On Tue, 29 Dec 2009 15:27:22 CST, "Serge E. Hallyn" said:
> > I think i disagree.  A uid is just a uid (or should be).  One day we may
> > have a way for a factotum-style daemon to grant the ability to an unpriv
> > task to setuid without CAP_SETUID.  I think slingling uids and gids
> > around that you already have access to should be fine.
> 
> Yes, but not doing the clear and obvious simple thing now for a "one day
> we may have" consideration seems a poor engineering tradeoff.
> 
> Yes, slinging uids and gids around *would* be nice.  But first we need a clear
> plan for making /usr/bin/newgrp a shell builtin - once that happens, *then*
> we can re-address this code. ;)

Absolutely agreed with the principle, but conflicted on the application.

I know earlier in the thread I said uid 0 even when unprivileged is
actually privileged merely by owning most of the system files.  But
in fact I think it helps to think more clearly when we separately
consider the cases of (a) changing uid, and (b) enhancing privilege.

That's why I was recommending implementation through securebits - what
we're basically saying is the task should never gain privilege.  And
effectively, since it won't have CAP_SETUID (unless it has and keeps it
in pI) it wont' be able to change uids.  But if we right off the bat
confuse changing uids with gaining privilege, I'm afraid we might end
up making some poor decisions.

Still, I won't say no to a check to refuse dropping the ability to
setuid to ensure that ruid=euid=suid and pP=pE=pI=empty.  It may
come back to bite us, but like I say I'm conflicted - willing to
go either way.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/