[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 4 Jul 2011 08:27:47 +0530
From: Balbir Singh <bsingharora@...il.com>
To: Vasiliy Kulikov <segoon@...nwall.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>, Al Viro <viro@...iv.linux.org.uk>,
David Rientjes <rientjes@...gle.com>, Stephen Wilson <wilsons@...rt.ca>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>, security@...nel.org,
Eric Paris <eparis@...hat.com>, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH 2/2] taskstats: restrict access to user
On Sat, Jul 2, 2011 at 1:06 PM, Vasiliy Kulikov <segoon@...nwall.com> wrote:
> On Thu, Jun 30, 2011 at 00:17 +0400, Vasiliy Kulikov wrote:
>> On Wed, Jun 29, 2011 at 06:57 +0530, Balbir Singh wrote:
>> > On Fri, Jun 24, 2011 at 5:39 PM, Vasiliy Kulikov <segoon@...nwall.com> wrote:
>> > > + task = find_task_by_vpid(s->pid);
>> > > + if (!task || __task_cred(task)->euid != cred->euid) {
>>
>> If consider this patch for inclusion, it also needs some check for
>> the listener root ability. __task_cred(task)->euid == 0 or smth like
>> that. But ptrace_task_may_access_current() is better.
>
> So... What to do with this patch? Should I resend it with euid==0 and
> rcu optimication, wait for the new ptrace interface or what?
>
>
Hi, Vasiliy,
Would it be possible to audit the entire taskstats structure to see
what fields should and should not be exposed. If a particular field
should not be exposed, we can fill it in with a special value
indicating additional permission is required to see it and fill in
those fields only when credentials match like you've shown
Does that make sense?
Balbir Singh
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
