[<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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists