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:	Tue, 22 Feb 2011 11:33:14 -0800
From:	Greg KH <gregkh@...e.de>
To:	Kees Cook <kees.cook@...onical.com>
Cc:	linux-kernel@...r.kernel.org, Eugene Teo <eugeneteo@...nel.sg>,
	Ralph Campbell <infinipath@...gic.com>,
	Roland Dreier <roland@...nel.org>,
	Sean Hefty <sean.hefty@...el.com>,
	Hal Rosenstock <hal.rosenstock@...il.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Miklos Szeredi <miklos@...redi.hu>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	Neil Brown <neilb@...e.de>, Matthew Wilcox <matthew@....cx>,
	James Morris <jmorris@...ei.org>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	Eric Paris <eparis@...isplace.org>,
	Nick Piggin <npiggin@...nel.dk>, Arnd Bergmann <arnd@...db.de>,
	Ian Campbell <ian.campbell@...rix.com>,
	Jarkko Sakkinen <ext-jarkko.2.sakkinen@...ia.com>,
	Tejun Heo <tj@...nel.org>,
	Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH 2/2] debugfs: only allow root access to debugging
 interfaces

On Tue, Feb 22, 2011 at 11:22:48AM -0800, Kees Cook wrote:
> On Tue, Feb 22, 2011 at 11:13:33AM -0800, Greg KH wrote:
> > On Tue, Feb 22, 2011 at 10:16:13AM -0800, Kees Cook wrote:
> > > Har har, I forgot --compose to "git send-email".
> > > 
> > > Anyway, with the continuing deluge of bugs in the "debug" filesystem, I
> > > would like to make that filesystem's root directory mode 0700 by default
> > > since it's filled with crazy stuff that regular users do not need to see.
> > 
> > But that will break existing users of this interface, right?
> > 
> > > Better to try to just close the door completely on all the stuff in there.
> > > It is, after all, supposed to only be used for debugging, right?
> > 
> > No, not really, people use it for all sorts of crazy things.
> > 
> > Remember, the only rule in debugfs is:
> > 	There are no rules in debugfs.
> 
> Right, which seems extremely dangerous to me. I think debugfs should either
> be:
>  a) used only by the root user (would prefer this was actually CAP_DEBUG or
>     something)
> or
>  b) used by userspace tools
> 
> But not both. Creating interfaces with no rules for userspace consumption
> is going to lead to disaster. You can't disallow "break[ing] existing
> users of this interface" and say there are no rules at the same time. :)

I'm not going to argue that the wisdom of putting userspace tool
interfaces in debugfs wasn't a bad idea, but that was not for me to
decide, it was the creators of that interface's decision.  And even
then, it was something the evolved over time and I doubt that anyone
when it was first created, would have imagined the perf interface being
in debugfs today.

And even then, there's been a proposal to move that to a new filesystem
which would solve that issue.

I will say that you can not break existing users, as I want all users to
have access to the debugfs files I have created in there for a wide
range of valid reasons.

So no, I'm not going to change the whole filesystem to not allow all
users to access it, that is a per-file/directory decision by the creator
of that file/directory.

Again, let's fix the real problems here, world-writable debugfs files.
Nothing different here from sysfs which had the same issues, just that
no one thought to ask for zillions of CVE entries to panic the world
with when we resolved all of them...

thanks,

greg k-h
--
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