From: Vasiliy Kulikov <segoon@openwall.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Shailabh Nagar <nagar@us.ibm.com>,
Balbir Singh <bsingharora@gmail.com>,
linux-kernel@vger.kernel.org, security@kernel.org,
Eric Paris <eparis@redhat.com>, Stephen Wilson <wilsons@start.ca>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
David Rientjes <rientjes@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Balbir Singh <balbir@linux.vnet.ibm.com>,
kernel-hardening@lists.openwall.com
Subject: [kernel-hardening] Re: [Security] [PATCH 2/2] taskstats: restrict access to user
Date: Thu, 30 Jun 2011 11:57:16 +0400 [thread overview]
Message-ID: <20110630075716.GB3377@albatros> (raw)
In-Reply-To: <BANLkTimm7KDEU7WD7jVV=5vAGt2GbjgwGg@mail.gmail.com>
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.
>
> 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.
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.
> 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.
>
> 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.
> but it seems to be some global cross-namespace
> thing too, so it exposes taskstats across pid namespaces afaik.
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
next parent reply other threads:[~2011-06-30 7:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1308917362-4795-1-git-send-email-segoon@openwall.com>
[not found] ` <BANLkTimm7KDEU7WD7jVV=5vAGt2GbjgwGg@mail.gmail.com>
2011-06-30 7:57 ` Vasiliy Kulikov [this message]
2011-06-30 10:59 ` [kernel-hardening] Re: [Security] [PATCH 2/2] taskstats: restrict access to user Balbir Singh
2011-06-30 12:08 ` Vasiliy Kulikov
2011-06-30 16:40 ` Linus Torvalds
2011-07-01 3:02 ` Balbir Singh
2011-09-19 16:40 ` Linus Torvalds
2011-09-19 17:20 ` Balbir Singh
2011-09-19 17:39 ` Vasiliy Kulikov
2011-09-19 17:45 ` Linus Torvalds
2011-09-20 3:35 ` Eric W. Biederman
2011-09-20 5:47 ` Alexey Dobriyan
2011-09-19 17:47 ` Balbir Singh
2011-09-19 18:29 ` Andi Kleen
2011-09-19 18:32 ` Linus Torvalds
[not found] ` <BANLkTi=dTHGK1QVs+g2tA6WocQ64SPPF3g@mail.gmail.com>
[not found] ` <20110629201718.GA11071@albatros>
2011-07-02 7:36 ` [kernel-hardening] " Vasiliy Kulikov
2011-07-04 2:57 ` Balbir Singh
2011-07-04 17:45 ` Vasiliy Kulikov
2011-07-07 8:55 ` Vasiliy Kulikov
2011-07-07 11:53 ` Balbir Singh
2011-07-07 16:23 ` Vasiliy Kulikov
2011-07-09 15:36 ` Balbir Singh
2011-07-11 14:07 ` Vasiliy Kulikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110630075716.GB3377@albatros \
--to=segoon@openwall.com \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=bsingharora@gmail.com \
--cc=eparis@redhat.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nagar@us.ibm.com \
--cc=rientjes@google.com \
--cc=security@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=wilsons@start.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox