Message-ID: <f73f7ab80912291102i22fb9e10v3b1b0eaba2e4f61d@mail.gmail.com>
Date:	Tue, 29 Dec 2009 14:02:43 -0500
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	Michael Stone <michael@...top.org>,
	"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>, Pavel Machek <pavel@....cz>
Subject: Re: A basic question about the security_* hooks

On Mon, Dec 28, 2009 at 20:43, Casey Schaufler <casey@...aufler-ca.com> wrote:
> Kyle Moffett wrote:
>> On Sat, Dec 26, 2009 at 14:50, Michael Stone <michael@...top.org> wrote:
>>> 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.
>>
>> [...]
>
> I would be very surprised if the policy you've described actually
> covered all the bases. I would also be surprised if a functional
> policy that meets the needs described was considerably smaller than
> Lake Michigan. It's really easy to toss off the basics of what needs
> to be done, it's quite another to get the whole thing right.
>
>> If all you need is something much simpler, the policy
>> language is very flexible and easy to customize.
>>
>
> I'm willing to bet all the beers you can drink in a sitting that
> the policy would be bigger than the proposed LSM. You can count that
> in either bytes or lines.

If that bet's in Mountain Dew or "Bawls" energy drinks
(http://www.bawls.com/) instead of beer... then you've got a deal :-D

Here's a very fast first cut at such a policy.  In this version I
actually completely ignore the type-enforcement mechanism, although if
you decide to start mediating file access then you may want to
reenable it.  The policy is pretty straightforward and easy to read...
customizations would initially mostly be in the "constraint" rules.

The only thing I actually had to write was the base-policy.pp file.  I
personally absolutely detest M4... so these particular files are
designed to be preprocessed with "cpp" instead.  Those 3 ".h" files
are simply lists of the kernel's access vectors and such run through
"sed" to convert the "#" comments into "//" comments.

I have a Makefile I've been using personally to build that policy, but
right now it's rather interdependent with my working environment, so
it may take me several days to find the time to extract it cleanly.

Cheers,
Kyle Moffett

Download attachment "access_vectors.h" of type "application/octet-stream" (8806 bytes)

Download attachment "base-policy.te" of type "application/octet-stream" (2332 bytes)

Download attachment "initial_sids.h" of type "application/octet-stream" (422 bytes)

Download attachment "security_classes.h" of type "application/octet-stream" (3670 bytes)

Powered by blists - more mailing lists