Message-ID: <f73f7ab80912280724l10aef7ber4d4dc8da5aeaafa2@mail.gmail.com>
Date:	Mon, 28 Dec 2009 10:24:01 -0500
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Michael Stone <michael@...top.org>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>, linux-kernel@...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>,
	Pavel Machek <pavel@....cz>
Subject: Re: A basic question about the security_* hooks

On Sat, Dec 26, 2009 at 14:50, Michael Stone <michael@...top.org> wrote:
>> I ask bc the API is in the prctl code, so the LSM
>> is conceptually always there, which is different from other LSMs.
>
> The goal is to provide a stupidly simple unprivileged per-process network
> isolation primitive which is broadly available "without jumping through
> hoops".
>
> (See http://cr.yp.to/unix/disablenetwork.html for a nice writeup.)
> I need a primitive like this to further my work on the OLPC Bitfrost
> security
> architecture and to further my more general work on advancing the state of
> sandboxing technology. (See sandboxing.org.)
>
> I'm willing to entertain pretty much any implementation or interface request
> which meets that goal and which implements the desired semantics.

If you aren't using SELinux at this time (and therefore have no
existing policy), then it's actually pretty straightforward
(relatively speaking) to set up for your particular goals.  On top of
that, once you actually get the system set up, it's very easy to
extend your sandbox security model to additional processes, actions,
etc.

In this example, you would set up a very minimal stripped-down SELinux
policy in which you only define 3 types (file_t, regular_t and
nonetwork_t).  Any process would be allowed to "dyntransition" from
regular_t to nonetwork_t, but not the reverse.  regular_t would be
allowed to do anything.  nonetwork_t would be allowed to do anything
that (A) does not involve the network *and* (B) does not compromise a
regular_t process.  file_t would only be used for on-disk files.

If you want to have some program binaries *automatically* run in
nonetwork_t, you would add 1 extra type: nonetwork_exec_t.  You would
include a rule "type_transition regular_t nonetwork_exec_t:process
nonetwork_t;" in your policy, and then allow anyone to relabel files
between the labels "file_t" and "nonetwork_exec_t".  Any program file
labelled "nonetwork_exec_t" would automatically execute as
"nonetwork_t" and therefore be properly sandboxed.

The default SELinux policies are rather fantastically complicated,
mainly because they have a goal of locking down an entire GUI-enabled
system.  If all you need is something much simpler, the policy
language is very flexible and easy to customize.

The best part is... when you discover you need to control additional
actions, you can do so at runtime with zero risk of crashing the
kernel (although you can always lock yourself into a box and force a
reboot with bad security policy).

Cheers,
Kyle Moffett
--
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