linux-kernel - Re: [PATCH] ptrace: allow restriction of ptrace scope

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100617215105.GB24749@outflux.net>
Date:	Thu, 17 Jun 2010 14:51:05 -0700
From:	Kees Cook <kees.cook@...onical.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Randy Dunlap <rdunlap@...otime.net>,
	James Morris <jmorris@...ei.org>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Dave Young <hidave.darkstar@...il.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Roland McGrath <roland@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	David Howells <dhowells@...hat.com>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-doc@...r.kernel.org, Stephen Smalley <sds@...ho.nsa.gov>,
	Daniel J Walsh <dwalsh@...hat.com>,
	linux-security-module@...r.kernel.org
Subject: Re: [PATCH] ptrace: allow restriction of ptrace scope

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/