public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 19:31:46 -0800	[thread overview]
Message-ID: <20110225033146.GA8526@suse.de> (raw)
In-Reply-To: <20110225011242.GY4212@outflux.net>

On Thu, Feb 24, 2011 at 05:12:42PM -0800, Kees Cook wrote:
> On Thu, Feb 24, 2011 at 04:35:08PM -0800, Greg KH wrote:
> > On Thu, Feb 24, 2011 at 04:22:14PM -0800, Kees Cook wrote:
> > > 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.
> 
> Since sysfs and proc have "rules", it discourages bad code more than
> debugfs does.

Oh yeah?  You should see the crap in proc :)

And I activly fight to keep the sysfs code sane, no reason why we can't
pay attention to debugfs as well, I just haven't been.

> > >  - 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.
> 
> I was careful in reproducing your earlier statement about not disagreeing.
> :)
> 
> > >  - 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?
> 
> If production systems should not have debugfs mounted, and the file is
> universally useful to non-root users, it should move like the perf
> interfaces, right?

No, the usb files have nothing to do with perf.

I do strongly feel that the perf files need to move out of debugfs and
have proposed perffs and tracefs numerous times in the past, patches
included, but it's up to the maintainers and developers of that code to
make that change, not me.

And if you do that, I see no reason to mount debugfs on any "enterprise"
system, which would be a great thing.

> > 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?
> 
> I don't feel that a test in checkpatch is sufficient to prevent future
> problems. What about Dan Carpenter's patch?

I have no objection to Dan's patch, it's in my "to-apply" queue and I
should get to it in a day or so.

thanks,

greg k-h

  reply	other threads:[~2011-02-25  3:31 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
2011-02-25  1:12                             ` Kees Cook
2011-02-25  3:31                               ` Greg KH [this message]
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=20110225033146.GA8526@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