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

[Kees Cook]

Hi James,

On Thu, Jul 01, 2010 at 11:39:01AM +1000, James Morris wrote:
> On Wed, 30 Jun 2010, Christoph Hellwig wrote:
> > Err, no.  This is just a very clear sign that your ptrace restrictions
> > were completely wrong to start with and break applications left, right
> > and center.  Just get rid of it instead of letting workarounds for your
> > bad design creep into the core kernel and applications.
> 
> Indeed, I wasn't aware that there were further aspects to this -- I 
> thought it was a relatively simple case of restricting a problematic OS 
> feature for heavily locked down systems.

That's certainly my intent, but PTRACE is kind of a nasty beast.

> This is getting more complicated, with fine-grained security policy now 
> being introduced, also with the need to modify applications.

Well, I'm trying to solve what I think is a core problem with PTRACE -- it
is too permissive.  I'm happy to look at it from other angles if it doesn't
make sense for this kind of thing to live in Yama.  I'm already very happy
with the existing restrictions available in Yama.

> 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
way for the kernel to intuit the relationship without the tracee
specifically declaring which process could PTRACE it, though.  Regardless
of the method, I think userspace changes would be needed for this kind of
thing.  I spent a little time discussing this within Ubuntu[1].

> If LSMs need to call into common code in Yama, or even do lightweight 
> chaining, that's one thing, but for Yama to evolve into yet another 
> standalone security scheme, is something entirely different.

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.

Thanks,

-Kees

[1] https://lists.ubuntu.com/archives/ubuntu-devel/2010-June/030939.html

-- 
Kees Cook
Ubuntu Security Team
--
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/