Re: [PATCH 0/2] Yama: add PTRACE exception tracking

[Serge E. Hallyn]

Quoting Kees Cook (kees.cook@xxxxxxxxxxxxx):
> On Thu, Jul 01, 2010 at 08:20:39AM -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.
> 
> Right, this was my thinking -- there is already one kind of declared
> relationship via TRACEME (though it's utility is for "pure" debugging).
> The other "regular" use of PTRACE is crash handlers, for which this is no
> declared relationship.  (If you ignore simple DAC, of course.)  The third
> PTRACE use is "arbitrary" debugging -- sysadmins or the like saying "wtf is
> that process DOING?"
> 
> When thinking about the PTRACE stuff originally, I hadn't realized the
> "crash handler" case.  So "pure" was done via TRACEME, and "arbitrary" was
> done via CAP_SYS_PTRACE, but there wasn't a clear way to declare the
> "crash" case.
> 
> > 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.
> 
> Actually, if you throw out process ancestry completely, and just use
> TRACEME and TRACEBY, everything still works.  The idea would be to just
> toss out the old definition of DAC PTRACE permissions.
> 
> > One q then is whether YAMA wants to provide task tracking of its own, or
> > stack with apparmor.
> 
> This is why I asked the question below... I don't want to reinvent the
> wheel, but from what I can see, no other LSM can do what I want...

(see below)

> > > 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.
> 
> Right, same for AppArmor.  With either system I can declare a binary as
> able to PTRACE another binary.  This is _still_ too permissive, IMO.  I

In SELinux you can specify which security contexts can be targets too.
I.e.

	allow serge_t serge_firefox_t:process ptrace;

I guess that in apparmor, it probably wouldn't quite be conventional to
specify '/usr/bin/firefox' as a target meaning any task confined in the
/usr/bin/firefox profile...

In smack, tasks have simple labels just like objects, and I believe
ptrace is taken as rw access to the label.

So, you say that

	> wheel, but from what I can see, no other LSM can do what I want...

It depends on if you want exactly what you say you want.  You can do
fine-grained ptrace controls based on security domains of both source
and target.  As for specifying one specific pid of a task which may
ptrace me, no, that doesn't work right now, but I'm not convinced it'd
be a good thing.

> want a process to directly specify which other process should be allowed to
> do a PTRACE.  The logic for this is, by its nature, only known to the
> tracee.  (i.e. "Oh, I'm crashing now... trigger handler... allow PTRACE.")
> 
> (Though obviously this isn't safe if the crasher handler allows arbitrary
> control of the process -- otherwise "kill -SEGV ..." is all that's needed
> to subvert the tracee.  The handler by its nature should just collect
> details and quit.  It's not a "debugging" case, it's a "crash" case.)
> 
> > > 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.
> 
> This doesn't appear to be true anymore.  Looking at the fs/proc/base.c and
> security/selinux/hooks.c code, there is no checking for a prepended LSM
> name.  Maybe that's the first chaining limitation -- you can't chain 2 LSMs
> that both declare setprocattr hooks.

No no, Stephen and I were talking about in the stacker patchset, again
around 2004-2005.  Never went upstream (per 2005 or 2006 ksummit
agreement).

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/