All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees.cook@canonical.com>
To: James Morris <jmorris@namei.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org, Randy Dunlap <rdunlap@xenotime.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jiri Kosina <jkosina@suse.cz>,
	Dave Young <hidave.darkstar@gmail.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Roland McGrath <roland@redhat.com>,
	Oleg Nesterov <oleg@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	David Howells <dhowells@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	linux-doc@vger.kernel.org, Stephen Smalley <sds@tycho.nsa.gov>,
	Daniel J Walsh <dwalsh@redhat.com>,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH] ptrace: allow restriction of ptrace scope
Date: Thu, 17 Jun 2010 10:04:53 -0700	[thread overview]
Message-ID: <20100617170453.GV24749@outflux.net> (raw)
In-Reply-To: <alpine.LRH.2.00.1006172336390.17282@tundra.namei.org>

Hi James,

On Thu, Jun 17, 2010 at 11:45:42PM +1000, James Morris wrote:
> On Wed, 16 Jun 2010, Kees Cook wrote:
> 
> [Note: it would be useful to cc: the LSM list on security discussions]

Sorry, I was blindly using get_maintainer output.

> > Certainly.  PTRACE can already be confined by SELinux and AppArmor.  I'm
> > looking for a general approach that doesn't require a system builder to
> > create MAC policies for unknown software.  I want to define a common core
> > behavior.
> > 
> > > And even if you don't care about using the same security stuff the rest
> > > of the world is using to solve the problem this like the other half baked
> > > stuff you posted for links belongs as a security module.
> > 
> > The LSM isn't stackable, so I can't put it there and choose this and
> > SELinux (for the case of software-without-a-policy).
> 
> SELinux already supports a global switch for ptrace via the allow_ptrace 
> boolean.  You don't need to write any policy, just set it to 0.
> 
> Global behavior can be further customized and refined (e.g. create a 
> generic policy module for apps without an existing policy, which allows 
> everything except things like ptrace and dangerous symlinks).
> 
> SELinux users would not need the other LSM, and stacking is thus not 
> required.

But if a user wants to disable ptrace using the SELinux LSM and then
also disable sticky-symlinks via the ItsHideous LSM, they're out of luck.

-Kees

-- 
Kees Cook
Ubuntu Security Team

  reply	other threads:[~2010-06-17 17:06 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-16 22:18 [PATCH] ptrace: allow restriction of ptrace scope Kees Cook
2010-06-16 23:01 ` Alan Cox
2010-06-16 23:22   ` Kees Cook
2010-06-17 13:45     ` James Morris
2010-06-17 17:04       ` Kees Cook [this message]
2010-06-17 20:53         ` Alan Cox
2010-06-17 21:06           ` Randy Dunlap
2010-06-17 21:16             ` Kees Cook
2010-06-17 22:18               ` Alan Cox
2010-06-17 22:25                 ` Kees Cook
2010-06-17 22:34                   ` Alan Cox
2010-06-17 21:18             ` Alan Cox
2010-06-17 21:51               ` Kees Cook
2010-06-17 22:30                 ` Alan Cox
2010-06-17 23:03                   ` James Morris
2010-06-18  3:10                   ` Casey Schaufler
2010-06-18 10:54                     ` Theodore Tso
2010-06-18 13:50                       ` Eric W. Biederman
2010-06-18 14:29                         ` Serge E. Hallyn
2010-06-19  2:23                         ` Casey Schaufler
2010-06-19  2:49                           ` Eric W. Biederman
2010-06-21  0:52                       ` James Morris
2010-06-21  2:16                         ` Valdis.Kletnieks
2010-06-18 17:58                   ` Kees Cook
2010-06-19  2:15                 ` Tetsuo Handa
2010-06-19  3:19                 ` Frank Ch. Eigler
2010-06-16 23:10 ` Roland McGrath
2010-06-16 23:39   ` Kees Cook
2010-06-17  0:11     ` Roland McGrath
2010-06-17  0:46       ` Kees Cook
2010-06-18 12:36       ` Serge E. Hallyn
2010-06-17 12:29 ` Eric W. Biederman
2010-06-17 16:59   ` Kees Cook
2010-06-17 20:45     ` Eric W. Biederman
2010-06-17 21:14       ` Kees Cook
2010-06-17 22:50       ` Serge E. Hallyn
2010-06-17 23:11         ` Eric W. Biederman

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=20100617170453.GV24749@outflux.net \
    --to=kees.cook@canonical.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dhowells@redhat.com \
    --cc=dwalsh@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=hidave.darkstar@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jkosina@suse.cz \
    --cc=jmorris@namei.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=rdunlap@xenotime.net \
    --cc=roland@redhat.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=sds@tycho.nsa.gov \
    /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.