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:11:29 +0100
From:	Pavel Machek <pavel@....cz>
To:	Michael Stone <michael@...top.org>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>, 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>,
	Valdis Kletnieks <Valdis.Kletnieks@...edu>,
	Bryan Donlan <bdonlan@...il.com>,
	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>,
	Al Viro <viro@...IV.linux.org.uk>
Subject: Re: RFC: disablenetwork facility. (v4)

Hi!

> I think that Pavel's point, at its strongest and most general, could be
> rephrased as:
> 
>   "Adding *any* interesting isolation facility to the kernel breaks 
>   backwards
>    compatibility for *some* program [in a way that violates security 
>    goals]."

Yep.

> So far, I've seen the following suggestions:
> 
>   a) setuid restores pre-isolation semantics
> 
>         - Doesn't work for me because it violates the security guarantee of 
>         the
>           isolation primitive 

d) when any new isolation feature requires removing ability to
exec(anything setuid) first.

>   b) setuid is an escape-hatch
> 
>         - Probably the cleanest in the long-run
> 
>         - Doesn't, by itself, suffice for Pavel since it violates backwards
>           compatibility
> 
>   c) signal to the kernel through a privileged mechanism that
>      backwards-incompatible isolation may or may not be used
> 
>         - No problems seen so far.


> I would be happy with (c), assuming we can agree on an appropriate 
> signalling
> mechanism and default.
> 
> So far, two defaults have been proposed:
> 
>   default-deny incompatible isolation (Pavel)


> So far, several signalling mechanisms have been proposed:
> 
>   1) enabling a kernel config option implies default-permit
> 
>         - My favorite; apparently insufficient for Pavel?
> 
>   2) default-deny; disablesuid grants disablenetwork
> 
>         - "disablesuid" is my name for the idea of dropping the privilege of
>           exec'ing setuid binaries
> 
>         - Suggested by Pavel and supported by several others. 

>         - I think it has the same backwards-compatibility problem as
>           disablenetwork: disablesuid is an isolation primitive.

Which is ok, use can already arbitrarily break *his own* apps, eg. by
using ptrace. Only with setuid in place it becomes security problem.

>   4) default-deny; setting a sysctl implies permit
> 
>         - Suggested by Serge; works fine for me
...
> I am happiest with (1) and, if (1) isn't good enough, with (4).
> 
> Pavel, what do you think of (4)?

It is still bad idea: (2) is better solution.
									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