Hi!

quoted

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