* Eric W. Biederman ([email protected]) wrote:
> "Serge E. Hallyn" <[email protected]> writes:
>
> > Frankly I thought, and am still not unconvinced, that containers owned
> > by someone other than the system owner would/should never want to load
> > their own LSMs, so that this wasn't a problem. Isolation, as Chris has
> > mentioned, would be taken care of by the very nature of namespaces.
>
> Up to uids I agree. Once we hit uids things get very ugly.
> And since security modules already seem to touch all of the places
> we need to touch to make a UID namespace work I think using security
> modules to implement the strange things we need with uid.
>
> To ensure uid isolation we would need a different copy of every other
> namespace. The pid space would need to be completely isolated,
> and we couldn't share any filesystem mounts with any other namespace.
> This especially includes /proc and sysfs.
Security modules use labels not uid's. The uid is the basis for
traditional DAC checks, the label are used for MAC checks. And its
easy to imagine a label that includes a notion of container id.
> However it is possible to build the capacity to multiplex
> compiled in or already loaded security modules, and allowed which
> security modules are in effect to be controlled by securityfs.
Yes, it's been proposed and discussed many times. There's some
fundamental issues with composing security modules. First and foremost
is the notion that arbritrary security models may not compose to form
meaningful (in a security sense) results. Second, at an implementation
level, sharing labels is non-trivial and comes with overhead.
> With appropriate care we should be able to allow the container
> administrator to use this capability to select which security
> policies, and mechanisms they want.
>
> That is something we probably want to consider anyway as
> currently the security modules break the basic rule that
> compiling code in should not affect how the kernel operates
> by default.
Don't follow you on this one.
thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
