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: <87d2xb3440.fsf@xmission.com>
Date:	Fri, 11 Jan 2013 11:35:11 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	John Johansen <john.johansen@...onical.com>,
	James Morris <jmorris@...ei.org>,
	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

Casey Schaufler <casey@...aufler-ca.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.
>
> Would that be per-container LSM lists? I hadn't thought about
> doing that, and don't know how you might implement it, but I
> suppose it could work.

Essentially per-container LSM lists.  The semantics would be that
first you perform the global LSM list checks, and then you perform
the container LSM list checks (with additional layers if containers are
nested).  For LSM modules that depend on security labels I think there
would be a conflict that would prevent nesting.

This is already implemented for capabilities.  Something is already
happening with apparmor.

In practice it may just be a matter of getting the LSMs to be aware of
the containers rather than having per container LSM lists.  Especially
as all of the hooks are called every time for every LSM.

The important part is that the effect be nested policy.  Having nested calls
is likely to be unnecessary and inefficient if there is much nesting of
containers going on.

Eric

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

Powered by blists - more mailing lists