|Main Archive Page > Month Archives > linux-kernel archives|
Now we are planning to submit LIDS to mainline. (As you know, it already written for supporing LSM for several years.)
When we will finish to re-write documentation and some FAQ, then we will be able to submit the patch.
Serge E. Hallyn wrote: (2007/10/09 03:00):
> Quoting Eric W. Biederman (email@example.com):
>> "Serge E. Hallyn" <firstname.lastname@example.org> 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
> 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.
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to email@example.com
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-- Kazuki Omo: firstname.lastname@example.org Group Manager, OSS Technology Center Diary: http://omok.livejournal.com - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html