linux-kernel - More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 16 Nov 2007 17:08:03 -0800
From:	Crispin Cowan <crispin@...spincowan.com>
To:	Peter Dolding <oiaohm@...il.com>
CC:	rmeijer@...all.nl, apparmor-dev@...ge.novell.com,
	LSM ML <linux-security-module@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>
Subject: More LSM vs. Containers (having nothing at all to do with the AppArmor
 Security Goal)

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/