Quoting Eric W. Biederman ([email protected]):
"Serge E. Hallyn" <[email protected]> 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-security-module" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
