Message-ID: <1277997731.15753.119.camel@moss-pluto.epoch.ncsc.mil>
Date:	Thu, 01 Jul 2010 11:22:11 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	Kees Cook <kees.cook@...onical.com>,
	James Morris <jmorris@...ei.org>,
	Christoph Hellwig <hch@...radead.org>,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] Yama: add PTRACE exception tracking

On Thu, 2010-07-01 at 08:20 -0500, Serge E. Hallyn wrote:
> First off, if you consider PTRACE_PTRACEME, and just consider this a more
> finegrained targeted version of that, it doesn't seem all that gross.  So
> maybe that's my fault for suggesting prctl as an easier-to-use in LSMs
> api, bc using a PTRACE_PTRACEDBY might just look cleaner.

TRACEME is an alternative mechanism (to ATTACH) for establishing a
tracing relationship, not a mechanism for expressing policy over ATTACH
requests.  The prctl was solely for configuring (Yama-specific) policy.

> Still, you say 'ptrace is too permissive', but a rebuttal to that is that,
> in a DAC system, ptrace uses what credentials it knows of to authorize.
> *You* can make it more finegrained by not insisting on running everything
> as a single user.
> 
> What you now are trying to do is find a new, natural relationship between
> tasks on a plain DAC system to provide finer-grained control.  The one you
> picked - process ancestry - doesn't perfectly fit, so you add changes and
> make it less clean.  The criticism of that is valid and needs to be
> discusssed.
> 
> Adding new relationships between tasks is what LSMs do - based on the
> policy-defined relationships between the security tasks of the respective
> domains.  And it feeld natural there - so it's natural for SELinux and
> apparmor to confine firefox to a domain that can't ptrace anything else
> (and maybe not itself).

Or to express whatever ptrace relationships you want to allow,
regardless of process ancestry.

> One q then is whether YAMA wants to provide task tracking of its own, or
> stack with apparmor.

Last I looked, apparmor did not support any kind of fine-grained ptrace
constraints, just a simple unconfined || same-profile || CAP_SYS_PTRACE
check.  Whereas SELinux lets you control it based on the particular
domain pairing.

> > > There are several existing LSMs with the ability to control ptrace, but as 
> > > part of a system-wide, coherent, analyzable policy -- often in support of 
> > > specific security models for which there is concrete user demand and 
> > > benefit.
> > 
> > Sure.  I am curious, though, is there a way for SELinux (or maybe Smack,
> > since it has more dynamic labels) to declare this kind of on-runtime PTRACE
> > relationship?  Maybe I overlooked some options for this.  I didn't see any
> 
> In SELinux, you could give a debugger or crash handler an unprivileged, but
> allowed-to-ptrace-the-main-app domain.

Exactly.  What we do not want to do is to have the applications
configuring policy on the fly.

> > I still think simple chaining is the way to go.  I want to review the
> > earlier discussions first (I think Serge said it was in 2004ish?) before I
> > write up anything.  There is, I think, one sticking point, which is
> > /proc/self/attr/current, but beyond that, I think some simple
> > reorganization of LSM initialization routines and a list that security_*
> > walks would be sufficient.
> 
> In the past, output results for each LSM were simply split by \n or a :
> or something, and input was prepended by the LSM name.

I think the final form of the stacker patches put each value on its own
line with the module name in parentheses after it.  But it required a
compatibility hack for SELinux and ultimately I think a libselinux patch
to support SELinux stacked with anything else that wanted to
use /proc/self/attr.

-- 
Stephen Smalley
National Security Agency

--
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/

Powered by blists - more mailing lists