linux-kernel - Re: taskstats root only breaking iotop

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 4 Oct 2011 17:31:26 +0400
From:	Vasiliy Kulikov <segoon@...nwall.com>
To:	Adrian Bunk <bunk@...sta.de>
Cc:	Guillaume Chazarain <guichaz@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Balbir Singh <bsingharora@...il.com>,
	kernel-hardening@...ts.openwall.com,
	Andrew Morton <akpm00@...il.com>
Subject: Re: taskstats root only breaking iotop

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@...ux-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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/