Quoting Eric W. Biederman (ebiederm@xmission.com):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 -
| Mariusz Kozlowski | [PATCH 12] fs/reiser4/plugin/file/cryptcompress.c: kmalloc + memset conversion to ... |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Eric Paris | Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on access scan... |
| Pardo | Re: pthread_create() slow for many threads; also time to revisit 64b context switc... |
git: | |
| Aaron Bentley | Re: VCS comparison table |
| Ken Pratt | pack operation is thrashing my server |
| Jonas Fonseca | Re: First cut at git port to Cygwin |
| Ingo Molnar | [OT] Your branch is ahead of the tracked remote branch 'origin/master' by 50 commi... |
| Richard Stallman | Real men don't attack straw men |
| Richard Stallman | Re: Real men don't attack straw men |
| GVG GVG | ssh_exchange_identification: Connection closed by remote host |
| Predrag Punosevac | Skype on the OpenBSD |
| Jim Winstead Jr. | Re: Root Disk/Book Disk Compatibility |
| Rick Emerson | Re: [comp.os.linux]: Re: File system issues! |
| Doug Evans | Re: Stabilizing Linux |
| Dong Liu | Re: CXterm for LINUX |
