Message-ID: <20071008180038.GC7106@vino.hallyn.com>
Date:	Mon, 8 Oct 2007 13:00:38 -0500
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	Kyle Moffett <mrmacman_g4@....com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Bill Davidsen <davidsen@....com>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	James Morris <jmorris@...ei.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	casey@...aufler-ca.com, linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory
	Access Control Kernel

Quoting Eric W. Biederman (ebiederm@...ssion.com):
> "Serge E. Hallyn" <serge@...lyn.com> writes:
> Also I'm thinking towards what do we have to do isolate the security
> module stuff in the context of a namespace.  So that a person in
> a container can setup their own rules that further restrict the
> system.

In the selinux example I plan to do set up soon, that will be done
using the '.' namespace separator.

Every object/subject in vserver1 will have a type 'vserver1.whatever'.
'vserver1.root_t', 'vserver1.etc_t', etc.

I don't know how far the policy tools have gotten, but they are
*supposed* to implement constraints at policy compile time such that
every type which is a child of 'vserver1' would have no more access than
what is granted to type 'vserver1'.  So this provides a pretty nice
conceptual way to set up security for a vserver.

Then using the userspace policy server and metapolicy (this would be a
step or two beyond my first example) the policy could define rules about
what sort of policy could be added by a process of type
'vserver1.root_t'.  So we can allow the container admin to introduce
policy changes affecting only his own container, and subject to all
constraints placed by the host admin on vserver1.

> So far I'm not ready to do anything yet but I'm keeping a weather eye
> on the situation so I have a clue what I'm go.
> 
> > If 1, an selinux policy should cover you.  So you can then skip to 3.
> > Or, alternatively, I do plan - as soon as my free time clears up a bit -
> > on demonstrating how to write some selinux policy to create a secure
> > container based on current -mm + your experimental network namespace
> > patches.
> 
> Thanks that sounds interesting.
> 
> > If 3, then selinux policy modules may actually help you, else either
> > a new LSM (maybe like LIDS) or a userspace tool which is a front-end to
> > selinux policy, emulating the iptables rules formats, may be what you
> > want?
> 
> I don't want to have to choose my LSM at compile time.  I want to
> add support into the kernel at compile time and be able to configure
> it before I go multi-user.  I know this kind of architecture is
> achievable because iptables allows it.
> 
> When I conceive as the security modules as just a firewall between
> applications on my own box I think, oh yeah this is no big deal,
> I might want to limit something that way some time.  These are just
> some additional rules on when to return -EPERM.  So I ask myself why
> is this situation much less flexible and much harder to use then our
> network firewall code?

It actually used to be far more flexible than it is now.  The consensus
appears to be that it's just too hard - at times impossible - to
properly label every object or subject at some point after they've all
been created (processes created, inodes read from disk, etc).  Two
examples:

	1. you've got pid 777.  How was it created?  Can you trust it's
	history?  In my DTE module I solved this by keeping track of the
	*full* invocation history until a policy was loaded.  I think
	tomoyo may do something similar.  But it's really not
	sufficient, especially since you don't even want a LSM loaded
	at all.  So you can't reduce it to 'boot_t executd init_t
	executed login_t executed shell_t', you have to keep track of
	every inode executed

	2. how do you reliably re-evaluate, for some file, what label
	to assign to it?  Do you guess at a pathname?  Do you trust that
	the inodes have been pre-labeled for every LSM, so when you load
	the LSM you can grab the xattrs?

So it's a valid question - do we address these sorts of concerns in
order to add flexibility, or do we keep things as simple as possible
and say that it's up to the distro, for instance, or a site local
security administrator, to define policy, so that flexibility really
is of very limited use?

> >> My impression is that selinux is one monolithic blob that doesn't
> >> allow me to incrementally add matching or action features that I
> >> find interesting.
> >
> > Actually with policy modules it gets much much better.  I have in fact
> > been able to pretty easily write a short policy module to, say, create
> > an selinux user which ran as root and had full access to the system to
> > do system setup for automated testing.  There is a learning curve in
> > having to look at existing modules for maybe a few days to get started,
> > but once you get started the policy modules do make it very easy to
> > add to current policy.
> 
> Ok. Interesting.  Are these kernel modules?

Policy modules, loaded through selinuxfs at any time using 'semodule'.

> Still while I get the general impression that selinux seems to be
> very close to a generic solution, and that selinux more or less has
> the architecture we might want.  I don't get the impression that
> selinux does this at a level that is open to other people doing
> interesting things.
> 
> So I still ask the question can we move this functionality down to
> the LSM in a way that will solve the composition problem between
> multiple security modules?

I've tried :)  At a less semantic and more purely technical level, using
the stacker module.  After a few years it was finally decided (at
ksummit 2006) that it simply wasn't useful.

Now perhaps the problem was that I didn't address semantic issues.
But it does sound to me like what you want is a particular flexible LSM.
Be it LIDS or SELinux, or something new.

> It really seems to me that the LSM as currently structured creates
> a large barrier to entry for people who have just this little thing
> they want to do that is not possible with any existing security
> module.

Yes and it's been made increasingly so far particularly because of the
perceived potential for 'abuse'.  So to be curt, allowing people like
you describe to do something small and interesting is deemed far less
important than making sure that the small thing they want to do fits
within the LSM mandate and is not a non-upstream module.

So that is the concern you would need to address before any other.

Still, I do think that selinux policy modules may do just what you want.
The main obstacle appears to be that the 'base' policy is so huge that
it's tough to get started to do something small.

You also might want to check out LIDS, as its rules are set up pretty
much the way you seem to want.

-serge
-
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