netdev - Re: RFC: disablenetwork facility. (v4)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 1 Jan 2010 16:06:04 +0100
From:	Pavel Machek <pavel@....cz>
To:	Bryan Donlan <bdonlan@...il.com>
Cc:	Valdis.Kletnieks@...edu, Michael Stone <michael@...top.org>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Andi Kleen <andi@...stfloor.org>, David Lang <david@...g.hm>,
	Oliver Hartkopp <socketcan@...tkopp.net>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Evgeniy Polyakov <zbr@...emap.net>,
	"C. Scott Ananian" <cscott@...ott.net>,
	James Morris <jmorris@...ei.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Bernie Innocenti <bernie@...ewiz.org>,
	Mark Seaborn <mrs@...hic-beasts.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Am?rico Wang <xiyou.wangcong@...il.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Samir Bellabes <sam@...ack.fr>,
	Casey Schaufler <casey@...aufler-ca.com>,
	"Serge E. Hallyn" <serue@...ibm.com>
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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html