From: Greg KH <gregkh@suse.de>
To: Kees Cook <kees.cook@canonical.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
David Daney <ddaney@caviumnetworks.com>,
linux-kernel@vger.kernel.org, Eugene Teo <eugeneteo@kernel.sg>,
Ralph Campbell <infinipath@qlogic.com>,
Roland Dreier <roland@kernel.org>,
Sean Hefty <sean.hefty@intel.com>,
Hal Rosenstock <hal.rosenstock@gmail.com>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Miklos Szeredi <miklos@szeredi.hu>,
"J. Bruce Fields" <bfields@fieldses.org>,
Neil Brown <neilb@suse.de>, Matthew Wilcox <matthew@wil.cx>,
James Morris <jmorris@namei.org>,
Stephen Smalley <sds@tycho.nsa.gov>,
Eric Paris <eparis@parisplace.org>,
Nick Piggin <npiggin@kernel.dk>, Arnd Bergmann <arnd@arndb.de>,
Ian Campbell <ian.campbell@citrix.com>,
Jarkko Sakkinen <ext-jarkko.2.sakkinen@nokia.com>,
Tejun Heo <tj@kernel.org>,
Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH 2/2] debugfs: only allow root access to debugging interfaces
Date: Thu, 24 Feb 2011 16:35:08 -0800 [thread overview]
Message-ID: <20110225003508.GB27272@suse.de> (raw)
In-Reply-To: <20110225002214.GW4212@outflux.net>
On Thu, Feb 24, 2011 at 04:22:14PM -0800, Kees Cook wrote:
> Hi Greg,
>
> On Tue, Feb 22, 2011 at 12:54:13PM -0800, Kees Cook wrote:
> > On Tue, Feb 22, 2011 at 12:37:04PM -0800, Greg KH wrote:
> > > On Tue, Feb 22, 2011 at 12:28:56PM -0800, Kees Cook wrote:
> > > > On Tue, Feb 22, 2011 at 12:16:10PM -0800, Greg KH wrote:
> > > > > On Tue, Feb 22, 2011 at 11:50:18AM -0800, Kees Cook wrote:
> > > > > > On Tue, Feb 22, 2011 at 07:34:18PM +0000, Alan Cox wrote:
> > > > > > > > What system do you proposed to keep these "stupid mistakes" from
> > > > > > > > continuing to happen? If debugfs had already been mode 0700, we could have
> > > > > > > > avoided all of these CVEs, including the full-blown local root escalation.
> > > > > > >
> > > > > > > And all sorts of features would have put themselves in sysfs instead and
> > > > > > > broken no doubt.
> > > > > > >
> > > > > > > > The "no rules" approach to debugfs is not a good idea, IMO.
> > > > > > >
> > > > > > > It's a debugging fs, it needs to be "no rules" other than the obvious
> > > > > > > "don't mount it on production systems"
> > > > > >
> > > > > > Okay, so the debugfs is not supposed to be mounted on a production system.
> > > > >
> > > > > No, not true at all, the "enterprise" distros all mount debugfs for good
> > > > > reason on their systems.
> > > >
> > > > What reasons are those? Or better yet, why do you and Alan Cox disagree on
> > > > this point?
> > >
> > > These distros have made the decision to support the perf interface,
> > > which lives in debugfs, for their customers. I'm not saying that I
> > > disagree with Alan about this, just pointing out the reality of the
> > > situation here.
> >
> > A tool used only by the root user, so the proposed mount mode of 0700
> > wouldn't break anything.
>
> The summary is this:
> - debugfs has been demonstrably dangerous to have available
Wait, I do not believe this statement at all.
It's like saying "sysfs and proc are demonstrably dangerous to have
available" because there were some bugs with some implementations of
sysfs and proc files in the past.
> - Alan Cox says that debugfs should not be used on production systems
> - Greg KH does not disagree
I also don't agree, as my day-job entails supporting a wide range of
production systems with this filesystem mounted and enabled.
> - however, pref needs it, and this is used by some root users
> - perf will likely move out of debugfs as some point
>
> What is the objection, then, to making the root of debugfs mode 0600? All
> the tools I reviewed that need it run as root (e.g. powertop). I've
> already written, tested, and sent the patches -- they would not break
> the requirements above.
There are a wide range of other files that can be safely read as a
normal user in debugfs. For example, the usb debugging files which we
use to help debug hardware controller issues. Now yes, we could ask the
user to become root first, but is that really necessary?
Again, I feel these were just a few bugs that do not reflect the much
larger and benificial use of this filesystem. We now have a set of
checks in place to prevent this type of error from occuring again, why
not rely on that instead of just removing the whole filesystem from
normal users entirely?
thanks,
greg k-h
next prev parent reply other threads:[~2011-02-25 0:35 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-22 18:09 [PATCH 1/2] fs: pass root inode mode to simple_fill_super Kees Cook
2011-02-22 18:09 ` [PATCH 2/2] debugfs: only allow root access to debugging interfaces Kees Cook
2011-02-22 18:16 ` Kees Cook
2011-02-22 18:32 ` David Daney
2011-02-22 18:47 ` Kees Cook
2011-02-22 19:14 ` Greg KH
2011-02-22 19:25 ` Kees Cook
2011-02-22 19:34 ` Alan Cox
2011-02-22 19:50 ` Kees Cook
2011-02-22 19:53 ` David Daney
2011-02-22 20:16 ` Greg KH
2011-02-22 20:28 ` Kees Cook
2011-02-22 20:37 ` Greg KH
2011-02-22 20:54 ` Kees Cook
2011-02-25 0:22 ` Kees Cook
2011-02-25 0:35 ` Greg KH [this message]
2011-02-25 1:12 ` Kees Cook
2011-02-25 3:31 ` Greg KH
2011-02-25 3:39 ` Al Viro
2011-02-22 19:54 ` Kees Cook
2011-02-22 19:43 ` Greg KH
2011-02-22 19:13 ` Greg KH
2011-02-22 19:22 ` Kees Cook
2011-02-22 19:33 ` Greg KH
2011-02-22 20:29 ` Dan Carpenter
2011-02-22 20:33 ` Kees Cook
2011-02-22 20:58 ` Henrique de Moraes Holschuh
2011-02-24 16:38 ` Steven Rostedt
2011-02-24 17:34 ` Henrique de Moraes Holschuh
2011-02-26 11:50 ` Arnd Bergmann
2011-02-25 19:56 ` Greg KH
2011-02-25 20:40 ` Hugh Dickins
2011-02-25 20:57 ` Greg KH
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=20110225003508.GB27272@suse.de \
--to=gregkh@suse.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arnd@arndb.de \
--cc=bfields@fieldses.org \
--cc=casey@schaufler-ca.com \
--cc=ddaney@caviumnetworks.com \
--cc=eparis@parisplace.org \
--cc=eugeneteo@kernel.sg \
--cc=ext-jarkko.2.sakkinen@nokia.com \
--cc=hal.rosenstock@gmail.com \
--cc=ian.campbell@citrix.com \
--cc=infinipath@qlogic.com \
--cc=jeremy.fitzhardinge@citrix.com \
--cc=jmorris@namei.org \
--cc=kees.cook@canonical.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=miklos@szeredi.hu \
--cc=neilb@suse.de \
--cc=npiggin@kernel.dk \
--cc=roland@kernel.org \
--cc=sds@tycho.nsa.gov \
--cc=sean.hefty@intel.com \
--cc=tj@kernel.org \
--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