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

From: Kees Cook
Date: Tue Jun 29 2010 - 23:51:17 EST


Hi Tetsuo,

On Wed, Jun 30, 2010 at 10:09:54AM +0900, Tetsuo Handa wrote:
> Kees Cook wrote:
> > +static spinlock_t ptracer_relations_lock;
> static DEFINE_SPINLOCK(ptracer_relations_lock);

Ah, very cool, I missed that while reading through spinlock code. :)

> > + relation = kzalloc(sizeof(*relation), GFP_KERNEL);
> You can use kmalloc() since all fields are initialized within this function.

I wasn't sure if list_add needed a zeroed ->node, so I opted for safety
here. Is list_add safe to use on an uninitialized ->node? (Looks like it
is on code review, I'll just use regular kmalloc.)

> > +static int ptracer_exception_found(struct task_struct *tracer,
> > + struct task_struct *tracee)
> > +{
> > + int rc = 0;
> > + struct ptrace_relation *relation;
> > + struct task_struct *parent = NULL;
> > +
> > + spin_lock(&ptracer_relations_lock);
> > + list_for_each_entry(relation, &ptracer_relations, node)
> > + if (relation->tracee == tracee) {
> > + parent = relation->tracer;
> > + break;
> > + }
> > + if (task_is_descendant(parent, tracer))
> > + rc = 1;
> > + spin_unlock(&ptracer_relations_lock);
>
> Can't we release ptracer_relations_lock before calling
> task_is_descendant() since task_is_descendant() won't
> access "struct ptrace_relation" on ptracer_relations list.

This is where it gets a little funny. I need to keep that lock so that
task_is_descendant isn't racing yama_task_free. I don't want to be in
the position where I've left the lock only to have another CPU free the
task_struct that was just located, so I have to keep the lock until I've
finished using "parent". (And I can't take the task with get_task since
it's already too late, and if I take it during _add, the task will never
be freed.)

> > @@ -32,27 +204,20 @@ static int yama_ptrace_access_check(struct task_struct *child,
> > {
> > int rc;
> >
> > + /* If standard caps disallows it, so does Yama. We should
> > + * should only tighten restrictions further.
> s/should should/should/

Agh, thanks.

-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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/