mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kees Cook <kees.cook@canonical.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Randy Dunlap <rdunlap@xenotime.net>,
	James Morris <jmorris@namei.org>,
	linux-kernel@vger.kernel.org,
	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 14:51:05 -0700	[thread overview]
Message-ID: <20100617215105.GB24749@outflux.net> (raw)
In-Reply-To: <20100617221815.68ce30c5@lxorguk.ukuu.org.uk>

On Thu, Jun 17, 2010 at 10:18:15PM +0100, Alan Cox wrote:
> > > Thats a nonsensical configuration so we don't care. If you are using
> > > SELinux you just do it via SELinux. If you are doing it via
> > > UbuntuHasToBeDifferent then you do it via that.
> > 
> > 
> > Well, surely there are people who use something other than Ubuntu
> > and also care about not using SELinux... eh?
> 
> Then they can load UbuntuSecurity and use that, just enabling the
> features they want.
> 
> I'm not against the Ubuntu stuff getting beaten into a security module
> and put where it belongs. Far from it - I just want to see it put where
> it belongs, which is not junk randomly spewed over the tree. Doubly so
> when they do it wrong *because* they are not using the security hooks.
> 
> It seems pretty easy to me. Kees needs to package up the grsecurity
> features that Ubuntu thinks are valuable into security/something/... with
> a set of sysfs entries to turn on/off the various features. Ubuntu is
> happy, people who want a simple set of sysfs feature controls for
> security are happy and nobody else will even notice.
> 
> It'll appeal to some people because it looks easy to work and it won't
> upset anyone else because its all nicely filed away where it belongs.

If all I cared about was the default Ubuntu distro, I wouldn't forward
these patches at all.  As it turns out, I care about all kinds of
configurations, e.g. people using SELinux on Ubuntu, AppArmor on SUSE,
no LSM on Fedora, grsecurity on Gentoo, or TOMOYO on Debian.  There are
all kinds of combinations, obviously, and I'm interested in making this
stuff available to anyone and everyone.

The "just use SELinux" reply is tiresome.  If "everyone" used SELinux,
there wouldn't be at least 3 other LSMs under active development.
Ignore that my email ends in "@canonical.com", as it seems to be
distracting these discussions.

The PTRACE, symlink, and other stuff are features people want.  If the
point of your argument is that the logic and configuration for each
of these features should be added to every LSM, that's not sensible.
An end user should be able to pick and choose what they want.  If I
create the security/hideous/ LSM tree, it would _exclude_ the ability to
use TOMOYO or Smack or SELinux or AppArmor.

At present, I'm aware of global PTRACE control being possible in SELinux,
AppArmor, grsecurity, and as a patch in Ubuntu's kernel.  I don't know
about TOMOYO or Smack, but configuring the default scope of PTRACE in
at least 4 different ways so far (or not being able to change it at all)
just seems crazy.

If the security API allowed the end user to pick and choose the features
they wanted, then those features would be developed in a single place
and configured in a single way.  Since that's not possible, I'm proposing
these features be central, and configured via /proc/sys.

-Kees

-- 
Kees Cook
Ubuntu Security Team

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

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-16 22:18 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
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 [this message]
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=20100617215105.GB24749@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®