All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: James Morris <jmorris@namei.org>
Cc: linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-fsdevel@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	Al Viro <viro@ftp.linux.org.uk>,
	Kees Cook <kees.cook@canonical.com>
Subject: Re: Preview of changes to the Security susbystem for 2.6.36
Date: Mon, 2 Aug 2010 08:24:21 -0400	[thread overview]
Message-ID: <20100802122421.GA12130@infradead.org> (raw)
In-Reply-To: <alpine.LRH.2.00.1008021216520.31941@tundra.namei.org>

On Mon, Aug 02, 2010 at 12:18:46PM +1000, James Morris wrote:
> On Fri, 30 Jul 2010, James Morris wrote:
> 
> > One issue which needs to be addressed is to confirm that there is 
> > consensus on the new Yama LSM module.  I had thought there was, based on 
> > list discussion, but have since had differing feedback.
> 
> I'm going to revert the Yama stuff for 2.6.36 -- Christoph has nacked it 
> to me off-list.

I'm also happy to do it on-list, but I really didn't want to do it
before I've actually validated the patches in your tree still are the
same that were objected before.

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.

Al gave you some very clear advice how a the sticky check should be
done for symlinks (if we need it at all, which I tend to disagree with),
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
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.

  parent reply	other threads:[~2010-08-02 12:24 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 [this message]
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=20100802122421.GA12130@infradead.org \
    --to=hch@infradead.org \
    --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 \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.