From: Valdis.Kletnieks@vt.edu
To: Christoph Lameter <cl@gentwo.org>
Cc: Vasiliy Kulikov <segoon@openwall.com>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Andrew Morton <akpm@linux-foundation.org>,
kernel-hardening@lists.openwall.com, Kees Cook <kees@ubuntu.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Christoph Lameter <cl@linux-foundation.org>,
Matt Mackall <mpm@selenic.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Dan Rosenberg <drosenberg@vsecurity.com>,
Theodore Tso <tytso@mit.edu>, Alan Cox <alan@linux.intel.com>,
Jesper Juhl <jj@chaosbits.net>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [kernel-hardening] Re: [RFC PATCH 2/2] mm: restrict access to /proc/slabinfo
Date: Mon, 19 Sep 2011 16:36:38 -0400 [thread overview]
Message-ID: <15820.1316464598@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Mon, 19 Sep 2011 15:02:34 CDT." <alpine.DEB.2.00.1109191502040.13103@router.home>
[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]
On Mon, 19 Sep 2011 15:02:34 CDT, Christoph Lameter said:
> On Mon, 19 Sep 2011, Valdis.Kletnieks@vt.edu wrote:
>
> > On Mon, 19 Sep 2011 12:51:10 CDT, Christoph Lameter said:
> >
> > > IMHO a restriction of access to slab statistics is reasonable in a
> > > hardened environment. Make it dependent on CONFIG_SECURITY or some such
> > > thing?
> >
> > Probably need to invent a separate Kconfig variable - CONFIG_SECURITY
> > is probably a way-too-big hammer for this nail. I can see lots of systems
> > that want to enable that, but won't want to tighten access to slab.
>
> There is already CONFIG_SECURITY_DMESG_RESTRICT. Generalize that setting
> to include all sorts of other kernel statistics?
The question becomes "What are the chances that a given site either will or
will not agree with using the same setting for all things aggregated under
the same option". I could probably make a good case for a flag
called CONFIG_SECURITY_INFOLEAK_RESTRICT that would be a switch
for "standard perms or root only" for all info-leaking files under /proc and
/sys.
The problem is that dmesg has *other* info-leakage issues - but it's not
internal kernel state, it's stuff like ipfilter messages and potentially
Selinux messages if auditd isn't running, and of late things like systemd and
crond like to stick crap in there as well.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
next prev parent reply other threads:[~2011-09-19 20:37 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20110910164001.GA2342@albatros>
2011-09-10 16:41 ` Vasiliy Kulikov
2011-09-12 15:06 ` Cyrill Gorcunov
2011-09-13 6:28 ` Vasiliy Kulikov
2011-09-14 13:16 ` Vasiliy Kulikov
2011-09-14 15:18 ` Dave Hansen
2011-09-14 15:42 ` [kernel-hardening] " Vasiliy Kulikov
2011-09-14 15:48 ` Vasiliy Kulikov
2011-09-14 18:24 ` Dave Hansen
2011-09-14 18:41 ` Dave Hansen
2011-09-14 19:14 ` Vasiliy Kulikov
2011-09-14 19:27 ` Kees Cook
2011-09-18 17:05 ` [kernel-hardening] " Vasiliy Kulikov
2011-09-19 13:42 ` Christoph Lameter
2011-09-19 14:30 ` Pekka Enberg
2011-09-19 14:46 ` Vasiliy Kulikov
2011-09-19 15:13 ` Pekka Enberg
2011-09-19 15:57 ` Vasiliy Kulikov
2011-09-19 16:11 ` Pekka Enberg
2011-09-19 16:18 ` Vasiliy Kulikov
2011-09-19 17:31 ` Pekka Enberg
2011-09-19 17:35 ` Vasiliy Kulikov
2011-09-19 17:51 ` Christoph Lameter
2011-09-19 19:59 ` Valdis.Kletnieks
2011-09-19 20:02 ` Christoph Lameter
2011-09-19 20:36 ` Valdis.Kletnieks [this message]
2011-09-19 17:51 ` Pekka Enberg
2011-09-19 17:58 ` Vasiliy Kulikov
2011-09-19 18:46 ` Pekka Enberg
2011-09-19 18:55 ` Vasiliy Kulikov
2011-09-19 19:20 ` Pekka Enberg
2011-09-19 19:33 ` Pekka Enberg
2011-09-19 18:55 ` Linus Torvalds
2011-09-19 19:18 ` Pekka Enberg
2011-09-19 19:45 ` Pekka Enberg
2011-09-19 20:59 ` David Rientjes
2011-09-19 18:03 ` Dave Hansen
2011-09-19 18:21 ` Pekka Enberg
2011-09-19 19:45 ` Valdis.Kletnieks
2011-09-19 19:55 ` Alan Cox
2011-09-21 17:05 ` Vasiliy Kulikov
2011-09-22 2:20 ` Valdis.Kletnieks
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=15820.1316464598@turing-police.cc.vt.edu \
--to=valdis.kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=alan@linux.intel.com \
--cc=cl@gentwo.org \
--cc=cl@linux-foundation.org \
--cc=drosenberg@vsecurity.com \
--cc=gorcunov@gmail.com \
--cc=jj@chaosbits.net \
--cc=kees@ubuntu.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=penberg@cs.helsinki.fi \
--cc=segoon@openwall.com \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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