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.
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?
Policy modules, loaded through selinuxfs at any time using 'semodule'.
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.
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
-
