From mboxrd@z Thu Jan  1 00:00:00 1970
From: Kees Cook <kees.cook@canonical.com>
Subject: Re: [PATCH] security: Yama LSM
Date: Mon, 21 Jun 2010 18:14:52 -0700
Message-ID: <20100622011452.GN24749@outflux.net>
References: <20100621213424.GG24749@outflux.net>
 <201006220028.o5M0Sbx7062650@www262.sakura.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <201006220028.o5M0Sbx7062650@www262.sakura.ne.jp>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

Hi Tetsuo,

On Tue, Jun 22, 2010 at 09:28:37AM +0900, Tetsuo Handa wrote:
> Kees Cook wrote:
> > +       /* require ptrace target be a child of ptracer on attach */
> > +       if (mode == PTRACE_MODE_ATTACH && ptrace_scope &&
> > +           !capable(CAP_SYS_PTRACE)) {
> > +               struct task_struct *walker = child;
> > +
> > +               read_lock(&tasklist_lock);
> 
> Holding tasklist_lock does not imply rcu protection.
> Don't you need rcu_read_lock() like setpriority() and getppid()?

You're totally right, thanks for the catch!  Looks like setpriority() does
a similar kind of thing, so I've wrapped the whole thing in rcu_ now:

...
+               rcu_read_lock();
                read_lock(&tasklist_lock);
                while (walker->pid > 0) {
...
                        rc = -EPERM;
                read_unlock(&tasklist_lock);
+               rcu_read_unlock();
...


-Kees

-- 
Kees Cook
Ubuntu Security Team