[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110630120831.GB7707@albatros>
Date: Thu, 30 Jun 2011 16:08:31 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: Balbir Singh <bsingharora@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Shailabh Nagar <nagar@...ibm.com>, linux-kernel@...r.kernel.org,
security@...nel.org, Eric Paris <eparis@...hat.com>,
Stephen Wilson <wilsons@...rt.ca>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
David Rientjes <rientjes@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Balbir Singh <balbir@...ux.vnet.ibm.com>,
kernel-hardening@...ts.openwall.com
Subject: Re: [Security] [PATCH 2/2] taskstats: restrict access to user
On Thu, Jun 30, 2011 at 16:29 +0530, Balbir Singh wrote:
> On Thu, Jun 30, 2011 at 1:27 PM, Vasiliy Kulikov <segoon@...nwall.com> wrote:
> > On Wed, Jun 29, 2011 at 13:09 -0700, Linus Torvalds wrote:
> >> Ok, having looked at this some more, I'm quite ready to just mark the
> >> whole TASKSTATS config option as BROKEN. It does seem to be a horrible
> >> security hazard, and very little seems to use it.
> >>
>
> I am not sure how you define BROKEN, BROKEN as per security rules?
> /proc/$pid/xxx also expose similar information.
I'm sure this information is also dangerous.
> >> It also seems to be really fundamentally broken. Afaik, there's no way
> >> to filter taskstats not only by security issues (Vasiliy's patch
> >> really is very ugly), but it seems to be some global cross-namespace
> >> thing too, so it exposes taskstats across pid namespaces afaik.
> >
> > The problem here is that it keeps a pid in a global list. This list is
> > then browsed by all namespaces. Looking into the code, I see 2 real
> > problems (didn't check, though):
> >
> > 1) If there are 2+ pid namespaces, one listener in pid_ns #1 and some
> > process dies in pid_ns #2, then the dying task wouldn't find the
> > listener via find_task_by_vpid() and would just delete the listener from
> > listeners list. Looks like this problem was created by optimization
> > patch f9fd8914c1acca0.
>
> I must admit, I did not pay much attention to pid namespace changes as
> they were being made to taskstats. I'll look at the code later this
> week.
>
> >
> > 2) Netlink sockets are per net namespace, but this accounting thing is per
> > pid namespace. So, if the dying task and the listener are in a single
> > pid namespace, but in different net namespaces, the message will not be
> > sent via genlmsg_unicast(). I suspect it is a problem of all non-net
> > netlink sockets.
This is not a problem of all non-net netlink sockets, but only of those
who finds a task by the pid. AFAIU, the normal netlink policy is using
broadcast packets.
3) A process cannot own 2 taskstats sockets because the information
stored in listeners array doesn't make difference between different
sockets of the same task. Both searches would stop on the first socket,
the first socket would receive 2 messages while the second would be
silent. It was introduced by f9fd8914c1acca0.
> Good catch, under what circumstances would tasks have the same pid
> namespace, but different net namespaces?
Umm, if one did unshare() or clone() to unshare only net namespace?
> >> It
> >> does that even with Vasiliy's patch, afaik, although then I think you
> >> need to have collissions in the namespaces if I read the code
> >> correctly.
> >>
> >> I suspect that could be fixed by adding a pid namespace to the
> >> 'listener' structure. Also adding a 'cred' pointer (or the actual
> >> listener thread pointer) to it would make Vasiliy's patch more
> >> palatable, since then you wouldn't need to look up the credentials at
> >> send_cpu_listeners() time.
> >>
>
> A simple work around could be to disable taskstats under network
> namespace or even the current behaviour should just warn the user that
> the network namespace of the listener is distinct and disallow the
> listener
>
> >> Maybe I have mis-read the code. But it does all make me shudder. There
> >> doesn't even seem to be all that many _users_ of the thing, so the
> >> problems it has really makes me go "is that code worth it"? We
> >> probably should never have merged it in the first place.
>
> iotop(), getdelays (in kernel) with many developers using it and many
> more. The interface has been published for a while now
>
> Thanks for the review,
> Balbir Singh
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
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.
