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

[John Johansen <john.johansen@canonical.com>]

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.