linux-kernel - Re: [PATCH v12 0/9] LSM: Multiple concurrent LSMs

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]

Message-ID: <50EF67BF.20200@canonical.com>
Date:	Thu, 10 Jan 2013 17:15:43 -0800
From:	John Johansen <john.johansen@...onical.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	James Morris <jmorris@...ei.org>,
	Casey Schaufler <casey@...aufler-ca.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	LSM <linux-security-module@...r.kernel.org>,
	LKLM <linux-kernel@...r.kernel.org>,
	SE Linux <selinux@...ho.nsa.gov>,
	Eric Paris <eparis@...hat.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Kees Cook <keescook@...omium.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v12 0/9] LSM: Multiple concurrent LSMs

On 01/10/2013 05:13 PM, Eric W. Biederman wrote:
> John Johansen <john.johansen@...onical.com> writes:
> 
>>> When a distro is run in a container it is desirable to be able to run
>>> the distro's security policy in that container.  Ideally this will get
>>> addressed by being able to do some level of per user namespace stacking.
>>> Say selinux outside and apparmor inside a container.
>>>
>>> I think this would take a little more work than what Casey has currently
>>> devised but I am hopeful an additional layer of stacking can be added
>>> after Casey has merged the basic layer of stacking.
>>>
>> Right the general case will take more, but doing things like selinux on
>> the outside and apparmor inside are doable right now. And we are working
>> on supporting stacked apparmor policy right now so apparmor outside and
>> a different apparmor policy inside will be doable soon.
> 
> Cool.  For stacked apparmor how are you deciding which tasks get which
> policy?  Is this based on user namespaces or something else?
> 
its based on the apparmor policy namespace, which is inherited from the
parent task.



--
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/