Messages in this thread | | | Subject | Re: [RFC] Virtualization steps | From | (Eric W. Biederman) | Date | Wed, 29 Mar 2006 20:01:20 -0700 |
| |
Sam Vilain <sam@vilain.net> writes:
> > We could even end up making security modules to implement standard unix > security. ie, which processes can send any signal to other processes. > Why hardcode the (!sender.user_id || (sender.user_id == target.user_id) > ) rule at all? That rule should be the default rule in a security module > chain. > > I just think that doing it this way is the wrong way around, but I guess > I'm hardly qualified to speak on this. Aren't security modules supposed > to be for custom security policy, not standard system semantics ?
It is simply my contention that you into at least a semi custom configuration when you have multiple users with the same uid. Especially when that uid == 0.
For guests you have to change the rule about what permissions a setuid root executable gets or else it will have CAP_SYS_MKNOD, and CAP_RAW_IO. (Unless I didn't read that code right).
Plus all of the /proc and sysfs issues.
Now perhaps we can sit down and figure out how to get completely isolated and only allow a new uid namespace when that is the case, but that doesn't sound to interesting.
So at least until I can imagine what the semantics of a new uid namespace are when we don't have perfect isolation that feels like a job for a security module.
Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |