linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Stroetmann <stroetmann@ontolinux.com>
To: Kees Cook <kees.cook@canonical.com>
Cc: James Morris <jmorris@namei.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-security-module <linux-security-module@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: Preview of changes to the Security susbystem for 2.6.36
Date: Mon, 02 Aug 2010 12:19:54 +0200	[thread overview]
Message-ID: <4C569BCA.3050603@ontolinux.com> (raw)
In-Reply-To: <20100802065746.GS3948@outflux.net>

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

  reply	other threads:[~2010-08-02 10:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-30  8:59 Preview of changes to the Security susbystem for 2.6.36 James Morris
2010-08-02  2:18 ` James Morris
2010-08-02  6:32   ` Kees Cook
2010-08-02  6:41     ` James Morris
2010-08-02  6:57       ` Kees Cook
2010-08-02 10:19         ` Christian Stroetmann [this message]
2010-08-02 16:36           ` Kees Cook
2010-08-02 17:33             ` Christian Stroetmann
2010-08-03 17:07               ` Kees Cook
2010-08-02 18:08           ` Serge E. Hallyn
2010-08-02 18:50             ` Christian Stroetmann
2010-08-02 12:24   ` Christoph Hellwig
2010-08-02 16:59     ` Kees Cook
2010-08-02 18:34       ` David P. Quigley
2010-08-03 17:04         ` Kees Cook
2010-08-02 18:51       ` Valdis.Kletnieks
2010-08-03 16:50         ` Kees Cook
2010-08-03 21:38           ` Valdis.Kletnieks
2010-08-03 22:34             ` Kees Cook
2010-08-04  2:07               ` Valdis.Kletnieks
2010-08-04  2:55                 ` Kees Cook
2010-08-04  3:54             ` Tetsuo Handa
2010-08-04  6:18               ` Valdis.Kletnieks
2010-08-04  7:00                 ` Tetsuo Handa
2010-08-04 16:23                   ` Valdis.Kletnieks
2010-08-04 12:21               ` Christian Stroetmann
2010-08-03 21:52           ` Christian Stroetmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C569BCA.3050603@ontolinux.com \
    --to=stroetmann@ontolinux.com \
    --cc=jmorris@namei.org \
    --cc=kees.cook@canonical.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).