linux-kernel - Re: [PATCH v5 0/3] security: Yama LSM

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-next>] [day] [month] [year] [list]

Date:	Thu, 17 Mar 2011 11:52:26 +1100 (EST)
From:	James Morris <jmorris@...ei.org>
To:	John Johansen <john.johansen@...onical.com>
cc:	Kees Cook <kees.cook@...onical.com>,
	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v5 0/3] security: Yama LSM

On Wed, 16 Mar 2011, John Johansen wrote:

> On 03/15/2011 06:35 PM, Kees Cook wrote:
> > On Tue, Mar 15, 2011 at 06:08:59PM -0700, Kees Cook wrote:
> >> This is an update of the Yama Linux Security Module.
> >>
> >> Now that there are attempts at permitting multiple active LSM modules,
> >> Yama should be reconsidered.
> > 
> Well not just that multiple active LSM modules are being reconsidered, but
> that YAMA is now being picked and used by a couple of other distros.

Distros should not be shipping out of tree code and then using that as a 
reason to ask for it to be merged.

We've obviously not reached a consensus on how to approach these security 
enhancements, so be aware that the final outcome upstream may not follow 
the approach that distros have already taken.

My preference is to see core security functionality incorporated into the 
core kernel where possible.

The purpose of LSM is to allow the configuration of different enhanced 
access control schemes (i.e. beyond Unix DAC).  Ad-hoc security 
enhancements which are not part of a coherent & distinct access control 
scheme should not be dropped into LSM simply because LSM has hooks in the 
right places, has security in the name, or because core developers pushed 
back on the code elsewhere.

Personally, I'd like to see the kernel offer as much hardening as possible 
for the general case, but this kind of work especially needs to be 
incorporated with full buy-in from core developers.

- James
-- 
James Morris
<jmorris@...ei.org>
--
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/