lkml.org 
[lkml]   [2010]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/2] Yama: add PTRACE exception tracking
Quoting Kees Cook (kees.cook@canonical.com):
> 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


\
 
 \ /
  Last update: 2010-07-01 21:43    [W:0.063 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site