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
next prev parent 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).