From: Kees Cook <kees.cook@canonical.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: James Morris <jmorris@namei.org>,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Al Viro <viro@ftp.linux.org.uk>
Subject: Re: Preview of changes to the Security susbystem for 2.6.36
Date: Mon, 2 Aug 2010 09:59:36 -0700 [thread overview]
Message-ID: <20100802165936.GV3948@outflux.net> (raw)
In-Reply-To: <20100802122421.GA12130@infradead.org>
Hi Christoph,
On Mon, Aug 02, 2010 at 08:24:21AM -0400, Christoph Hellwig wrote:
> As mentioned a few times during the past discussion moving broken
> code into a LSM doesn't magically fix it. In fact YAMA is not any kind
> of (semi-)coherent security policy like Selinux, smack or similar but
> just a random set of hacks that you didn't get past the subsystem
> maintainers.
I would love to have these "hacks" in the subsystem directly. But no one
has stepped forward to decode Al Viro's hints.
I'm getting pretty tired of moving this logic back and forth between the
subsystems and an LSM. You yourself told me to put these things in an
LSM[1], and yet now you're saying I shouldn't.
> Al gave you some very clear advice how a the sticky check should be
This is patently false. "Very clear advice" would have included actionable
instructions. He (and everyone else) has ignored my requests for
clarification[2]. If you see how the check should be implemented, please
send a patch demonstrating how. I would greatly prefer having these
protections in the VFS itself.
> done for symlinks (if we need it at all, which I tend to disagree with),
I can see how one might disagree with it, but anyone who handles day-to-day
security threats understands this protection to be a clear and obvious
solution for the past decade.
> and the ptrace check completely breaks crash handlers that we have
> in all kinds of applications. If you can get it into the main ptrace
I've seen two so far. Both are addressed with a one line fix. And I would
stress that no other existing subsystem in the kernel can provide the same
level of control that my ptrace exception logic provides. SELinux cannot do
this.
> code past Roland and Oleg that's fine, but just pushing it out into
> a tree that has percieved easier merge criteria doesn't work.
This advice is precisely counter to prior advise. It would seem that no one
knows how to handle these patches. I find it very simple; either:
- let me put them in an LSM that people can choose to enable
- help me get the patches into shape for the subsystems directly
Since the latter has been repeatedly denied, the former was suggested to
me, which I implemented. The option "give up" is not available to me.
Perhaps there is another option I could choose from so I can get these
protections into the mainline kernel?
-Kees
[1] http://lkml.org/lkml/2010/6/1/78
[2] http://lkml.org/lkml/2010/6/4/44
--
Kees Cook
Ubuntu Security Team
next prev parent reply other threads:[~2010-08-02 16:59 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
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 [this message]
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=20100802165936.GV3948@outflux.net \
--to=kees.cook@canonical.com \
--cc=hch@infradead.org \
--cc=jmorris@namei.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=viro@ftp.linux.org.uk \
/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