Messages in this thread |  | | | Date | Fri, 1 Jan 2010 16:06:04 +0100 | | From | Pavel Machek <> | | Subject | Re: RFC: disablenetwork facility. (v4) |
| |
Hi!
> > it is really only required for binaries setuid to someone else, but > > that would be too ugly. (Plus, as someone said, ping is great for > > leaking data out.) > > No, this is not sufficient; one needs only to find a setuid process > that can be convinced to run a program with the original (pre-suid)
Ok.
> Or one can target a non-root setuid program that may have security > holes - how about nethack?
Well, security holes are bad idea, who'd know?
> That said, I do feel this is a separate issue. The process should > first drop its ability to suid; then it can freely apply additional > restrictions without there being any risk of breaking setuid > applications.
ACK.
> In short, how does this sound: > * Add an API to allow processes to permanently revoke their own > ability to gain privileges from setuid-exec > * Add this disablenetwork facility, conditional on dropping > setuid-exec abilities > > This also paves the way for: > * Allow processes that have dropped said suid ability to freely create > new namespaces (and chroot)
Works for me.
> Which, combined with doing whatever audits are necessary to allow > cross-network-namespace uses of unix domain sockets, actually > eliminates the need for the disablenetwork API. :)
Cool ;-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
|  |