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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100630035109.GK4837@outflux.net>
Date:	Tue, 29 Jun 2010 20:51:09 -0700
From:	Kees Cook <kees.cook@...onical.com>
To:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH 2/2] Yama: add PTRACE exception tracking

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