linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <kees.cook@canonical.com>
To: "David P. Quigley" <dpquigl@tycho.nsa.gov>
Cc: Christoph Hellwig <hch@infradead.org>,
	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: Tue, 3 Aug 2010 10:04:04 -0700	[thread overview]
Message-ID: <20100803170404.GH3948@outflux.net> (raw)
In-Reply-To: <1280774061.2673.115.camel@moss-terrapins.epoch.ncsc.mil>

Hi David,

On Mon, Aug 02, 2010 at 02:34:21PM -0400, David P. Quigley wrote:
> On Mon, 2010-08-02 at 09:59 -0700, Kees Cook wrote:
> [...snip]
> > 
> > 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.
> > 
> 
> Would you mind explaining to me what you believe this patch can do that
> SELinux can't? Based on what I read in the kconfig entry for the feature
> and the subsequent exception patch I'm not seeing anything here that
> SELinux can't do. If there is something we are missing I'd like to
> understand it so we can make the decision on whether or not our ptrace
> access control checks need to be modified.

Sure thing. When looking at how PTRACE is used, it seemed clear that there
were exactly 2 use-cases:
 - tracking children (either for monitoring or debugging)
 - in-memory crash handlers

Allowing child-tracing was easy: this is discoverable through process
ancestry. Doing the crash handlers is different, since the handler can come
from anywhere. One thing that seemed common was that the crashing program
would know which pid was going to attach to it, so if those programs
declared to the kernel which pid is allowed to attach, then it could make
an exception for it. I did not find a heuristic approach that the kernel
could use to figure this out for itself (maybe I missed something).

It seems to me that SELinux (and AppArmor and maybe others?) can
declare general relationships of who can PTRACE who, etc, but nothing
that specifically says "only _this_ instance". Instead of "the crash
handler binary running as $identity can attach to program foo running
as $identity", it is "the crash handler process specified by program foo
at the time of the crash, can attach to foo", which is much more specific.

If there's a way to do this already, I am genuinely interested to learn
more about it. Perhaps I've grossly misunderstood something.

-Kees

-- 
Kees Cook
Ubuntu Security Team

  reply	other threads:[~2010-08-03 17:04 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
2010-08-02 18:34       ` David P. Quigley
2010-08-03 17:04         ` Kees Cook [this message]
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=20100803170404.GH3948@outflux.net \
    --to=kees.cook@canonical.com \
    --cc=dpquigl@tycho.nsa.gov \
    --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;
as well as URLs for NNTP newsgroup(s).