From: Vasiliy Kulikov <segoon@openwall.com>
To: Adrian Bunk <bunk@stusta.de>
Cc: Guillaume Chazarain <guichaz@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Balbir Singh <bsingharora@gmail.com>,
kernel-hardening@lists.openwall.com,
Andrew Morton <akpm00@gmail.com>
Subject: Re: taskstats root only breaking iotop
Date: Tue, 4 Oct 2011 17:31:26 +0400 [thread overview]
Message-ID: <20111004133125.GA11257@albatros> (raw)
In-Reply-To: <20111003123158.GA28898@localhost.pp.htv.fi>
On Mon, Oct 03, 2011 at 15:31 +0300, Adrian Bunk wrote:
> On Sun, Oct 02, 2011 at 02:54:57PM +0400, Vasiliy Kulikov wrote:
> > (cc'ed kernel-hardening)
> >
> > On Sun, Oct 02, 2011 at 12:22 +0200, Guillaume Chazarain wrote:
> > > On Sun, Oct 2, 2011 at 2:20 AM, Linus Torvalds
> > > <torvalds@linux-foundation.org> wrote:
> > > > So I don't see why you ask for it. What could possibly be a valid use-case?
> > >
> > > Right, kbyte granularity is enough.
> >
> > It is not enough. In some border cases an attacker may still learn
> > private information given the counters with _arbitrary_ granularity:
> >
> > http://www.openwall.com/lists/oss-security/2011/06/29/9
>
> If you request a CVE for that, shouldn't there also be a CVE for
> /proc/<pid>/cmdline being readable by all users?
>
> I'd expect "ps -ef" to be more likely to give private information to an
> attacker than counters with kbyte granularity, or am I wrong on that?
I agree that world-readable cmdline can be a privacy issue in some
cases. I tried to push a patch introducing procfs mount option to
restrict /proc/PID/ to PID owner to address the issue (as world-readable
cmdline and other files are already used by plenty of programs and
unconditionally breaking backward compatibility is not good, a
configuration mechanism is needed), but it didn't receive positive
feedback. A more detailed explanation from Solar Designer:
http://www.openwall.com/lists/kernel-hardening/2011/06/20/5
Andrew Morton complained that it is too specific to our needs and one
might want to define more fine granted procfs security model:
http://www.openwall.com/lists/kernel-hardening/2011/06/21/3
I've tried to address it and defined per-file policy:
http://www.openwall.com/lists/kernel-hardening/2011/08/10/12
No comments so far :(
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
next prev parent reply other threads:[~2011-10-04 13:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-01 21:54 taskstats root only breaking iotop Guillaume Chazarain
2011-10-01 21:59 ` Linus Torvalds
2011-10-01 22:41 ` Guillaume Chazarain
2011-10-02 0:20 ` Linus Torvalds
2011-10-02 10:22 ` Guillaume Chazarain
2011-10-02 10:54 ` Vasiliy Kulikov
2011-10-03 12:31 ` Adrian Bunk
2011-10-04 13:31 ` Vasiliy Kulikov [this message]
2011-10-03 14:52 ` Balbir Singh
2011-10-03 15:20 ` Linus Torvalds
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=20111004133125.GA11257@albatros \
--to=segoon@openwall.com \
--cc=akpm00@gmail.com \
--cc=bsingharora@gmail.com \
--cc=bunk@stusta.de \
--cc=guichaz@gmail.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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