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

Message-ID: <4D81696C.9020805@canonical.com>
Date:	Wed, 16 Mar 2011 18:52:44 -0700
From:	John Johansen <john.johansen@...onical.com>
To:	James Morris <jmorris@...ei.org>
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 03/16/2011 05:52 PM, James Morris wrote:
> 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.
> 
that wasn't actually my intent (though I will admit it kind of appears that
way), I was merely trying to say others are finding it useful.  That the YAMA
enhacements should be reconsidered, whether that be in the current form or
another.  I actually quite liked Casey's suggestion of splitting the controls

> 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.
> 
true enough and distros who choose to ship something before upstream takes
it will have to deal with any breakage or incompatibilities.

> 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.
>
Hrrmm, well I expect I have a slightly different take on this from both an
LSM and core dev pov.

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

Well I will agree that it needs to be hashed out again, and then maybe even
again and the best possible implementation needs to be settled on :)

I'm not arguing that YAMA needs to be taken in its current, just that it
implements features I would really like to see upstream.
--
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/