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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 14 Sep 2011 19:42:29 +0400
From:	Vasiliy Kulikov <segoon@...nwall.com>
To:	kernel-hardening@...ts.openwall.com
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Pekka Enberg <penberg@...nel.org>,
	Matt Mackall <mpm@...enic.com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, Dan Rosenberg <drosenberg@...curity.com>,
	Theodore Tso <tytso@....edu>, Alan Cox <alan@...ux.intel.com>,
	Jesper Juhl <jj@...osbits.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [kernel-hardening] Re: [RFC PATCH 2/2] mm: restrict access to
 /proc/slabinfo

Hi Dave,

On Wed, Sep 14, 2011 at 08:18 -0700, Dave Hansen wrote:
> On Wed, 2011-09-14 at 17:16 +0400, Vasiliy Kulikov wrote:
> > > World readable slabinfo simplifies kernel developers' job of debugging
> > > kernel bugs (e.g. memleaks), but I believe it does more harm than
> > > benefits.  For most users 0444 slabinfo is an unreasonable attack vector.
> > 
> > Please tell if anybody has complains about the restriction - whether it
> > forces someone besides kernel developers to do "chmod/chgrp".  But if
> > someone want to debug the kernel, it shouldn't significantly influence
> > on common users, especially it shouldn't create security issues. 
> 
> Ubuntu ships today with a /etc/init/mounted-proc.conf that does:
> 
> 	chmod 0400 "${MOUNTPOINT}"/slabinfo
> 
> After cursing Kees's name a few times, I commented it out and it hasn't
> bothered me again.  

Another way is chgrp slabinfo to some "admin" group which are privileged
in this sense and add your user to this group.  But please, sane and
secure defaults!

> I expect that the folks that really care about this (and their distros)
> will probably have a similar mechanism.  I guess the sword cuts both
> ways in this case: it obviously _works_ to have the distros do it, but
> it was a one-time inconvenience for me to override that.
> 
> In other words, I dunno.  If we do this in the kernel, can we at least
> do something like CONFIG_INSECURE to both track these kinds of things
> and make it easy to get them out of a developer's way?

What do you think about adding your user to the slabinfo's group or
chmod it - quite the opposite Ubuntu currently does?  I think it is more
generic (e.g. you may chmod 0444 to allow all users to get debug
information or just 0440 and chgrp admin to allow only trusted users to
do it) and your local policy doesn't touch the kernel.

Thanks,

-- 
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ