linux-kernel - Re: Preview of changes to the Security susbystem for 2.6.36

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C569BCA.3050603@ontolinux.com>
Date:	Mon, 02 Aug 2010 12:19:54 +0200
From:	Christian Stroetmann <stroetmann@...olinux.com>
To:	Kees Cook <kees.cook@...onical.com>
CC:	James Morris <jmorris@...ei.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-security-module <linux-security-module@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: Preview of changes to the Security susbystem for 2.6.36

Aloha James, Aloha Kees;
Ont the 02.08.2010 08:57,  Kees Cook wrote:
> On Mon, Aug 02, 2010 at 04:41:08PM +1000, James Morris wrote:
>    
>> On Sun, 1 Aug 2010, Kees Cook wrote:
>>      
>>> Well, at least I'll have something for my summit presentation again.
>>>
>>> On the other hand, it's rather hard for me to defend against a private NAK.
>>>        

A private NAK against a company's developer's OK
Where is the difference private and company? I thought that it doesn't 
matter who and what a developer is, and where she/he comes from.

>> It's the same nak as before -- I concluded there was consensus on the
>> lists, but was wrong.
>>      

The opinion as well as the NAK by Christoph was discussed and supported 
by other developers.

>>> James, will it stay in security-testing for .37 hopefully?
>>>        
>> Not with this approach, I'd imagine.
>>      

Yes, because it supports as an experiment the development of the LSM 
architecture in general.

> I'm sorry to appear dense, but the most recent NAK from Christoph was
> here[1], which was for a patch to Yama that is not in security-testing
> yet. Prior to that, all I could find was this[2] which explicitly asked
> me to put stuff in a special LSM.
>    

That is not quite right.
It is correct that this special Yama LSM was accepted so far. The 
inclusion into mainline was not an issue at that time.
But we discussed as well that the problem of chaining of small or large 
LSMs is not an argument for the existence of the Yama LSM, and that the 
LSM architecture should be developed further so that all of the 
functionalities of other securtiy packages without an LSM can be 
integrated as a whole by a new version of the LSM system in the future 
and not by ripping them of like it was done with the Yama LSM [3].
You can see these objections [3] as a second NAK, but now from a 
company's developer (I haven't said this before, because I'm not a hard 
core kernel developer).

> I really would like to see it in mainline, but next steps are not clear.
>
> -Kees
>
> [1] http://lkml.org/lkml/2010/6/30/31
> [2] http://lkml.org/lkml/2010/6/1/78
>
>    

[3] http://lkml.org/lkml/2010/6/30/64

Have fun in the sun
Christian Stroetmann
--
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/