Peter Dolding wrote:
>>> What is left unspecified here is 'how' a child 'with its own profile' is
>>> confined here. Are it is confined to just its own profile, it may that
>>> the "complicit process" communication may need to be wider specified to
>>> include this.
>>>
> Sorry have to bring this up. cgroups why not?
Because I can't find any documentation for cgroups? :)
> Assign application to
> a cgroup that contains there filesystem access permissions. Done
> right this could even be stacked. Only give less access to
> application unless LSM particularly overrides.
>
This comes no where close to AppArmor's functionality:
* Can't do learning mode
* Can't do wildcards
* Sucks up huge loads of memory to do that much FS mounting (imagine
thousands of bind mounts)
* I'm not sure, but I don't think you can do file granularity, only
directories
> There are reasons why I keep on bring containers up it changes the
> model. Yes I know coming to a common agreement in these sections will
> not be simple. But at some point it has to be done.
>
Containers and access controls provide related but different functions.
Stop trying to force containers to be an access control system, it does
not fit well at all.
Rather, we need to ensure that LSM and containers play well together.
What you proposed in the past was to have an LSM module per container,
but I find that absurdly complex: if you want that, then use a real VMM
like Xen or something. Containers are mostly used for massive virtual
domain hosting, and what you want there is as much sharing as possible
while maintaining isolation. so why would you corrupt that with separate
LSM modules per container?
What makes sense to me is to ensure that it is easy for an LSM module to
have a policy per container. This is relatively easy to do, and maps
very well to the primary use of containers for hosting virtual domains.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
CEO, Mercenary Linux http://mercenarylinux.com/
Itanium. Vista. GPLv3. Complexity at work
-
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]
