Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, Oct 02, 2018 at 03:57:30PM -0600, Shuah Khan wrote:
> On 10/02/2018 03:37 PM, Mauro Carvalho Chehab wrote:
> > Em Tue, 2 Oct 2018 09:30:01 -0700
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> > 
> >> On Tue, Oct 02, 2018 at 09:17:30AM -0700, Greg Kroah-Hartman wrote:
> >>> On Tue, Oct 02, 2018 at 10:00:29AM -0600, Shuah Khan wrote:  
> >>>> On 10/02/2018 08:59 AM, Olof Johansson wrote:  
> >>>>> On Tue, Oct 2, 2018 at 6:07 AM Steven Rostedt <rostedt@goodmis.org> wrote:  
> >>>>>>
> >>>>>> On Mon, 1 Oct 2018 18:18:56 -0700
> >>>>>> Greg KH <gregkh@linuxfoundation.org> wrote:
> >>>>>>  
> >>>>>>> On Mon, Oct 01, 2018 at 02:04:02PM -0400, Steven Rostedt wrote:  
> >>>>>>>> At Kernel Recipes, I talked with some people that have mature
> >>>>>>>> interfaces in the debugfs directory, but they can not access them on
> >>>>>>>> systems that have debugfs disabled. What would be the process to have
> >>>>>>>> these systems move out of debugfs? Should they create their own fs and
> >>>>>>>> be mounted in /sys/kernel, with a dedicated directory if the file system
> >>>>>>>> is enabled in the kernel (I had tracefs do that).
> >>>>>>>>
> >>>>>>>> Is this something we should discuss at Maintainers Summit? What is the
> >>>>>>>> process for mature debugfs directories? What's the justification to
> >>>>>>>> have them moved? Is there a better answer for this?  
> >>>>>>>
> >>>>>>> It's a technical topic, so maintainers summit doesn't make sense.
> >>>>>>>
> >>>>>>> Stuff in debugfs should NEVER be used for anything "real" or anything
> >>>>>>> other than debugging.  So I would argue that that code needs to be fixed
> >>>>>>> up now anyway, as most distros are disabling debugfs for the obvious
> >>>>>>> reasons (and Android is also turning it off).  
> >>>>>>
> >>>>>> The funny part is, things used for debugging tend to turn into
> >>>>>> something that people want on production systems (tracing,
> >>>>>> perf, powertop, etc).
> >>>>>>  
> >>>>>>>
> >>>>>>> As for where to put it, it all depends on exactly what it is, and what
> >>>>>>> it does and who uses it.  So it's almost always a case-by-case basis.
> >>>>>>>
> >>>>>>> Any specific examples you wish to share of code that needs this?
> >>>>>>>  
> >>>>>>
> >>>>>> tracefs was one example, but someone was talking to me at Kernel
> >>>>>> Recipes and wanted had another directory in debugfs and wanted it out
> >>>>>> as it was stable and wanted it exposed when debugfs is turned off.
> >>>>>> Unfortunately, this was discussed at an evening event, and I don't
> >>>>>> recall the specifics.  
> >>>>>
> >>>>> One really useful criteria for graduating some service to sysfs would
> >>>>> be to have namespaces and security aspects sorted out for it. Being in
> >>>>> debugfs you can ignore all of that.  
> >>>>
> >>>> Yes. Moving to debugfs service to sysfs would make it more secure. However,
> >>>> security is important even if it stays in debugfs.
> >>>>
> >>>> I don't believe that is safe to have a lower security bar for dbugfs
> >>>> interfaces. Not all distros disable debugfs and if debugfs becomes
> >>>> vulnerability, it would become target on distros that don't disable.  
> >>>
> >>> Until about 8 months or so ago, maybe a year, debugfs was totally
> >>> insecure and it was very trivial to use to crash the kernel.  Which is
> >>> why it is a good idea to lock it down and not mount it on "untrusted"
> >>> systems.  
> >>
> >> Based on a discussion on another thread on a public list, there are
> >> still remaining issues with debugfs that can cause major problems.  So
> >> no one should ever mount it on an untrusted system still.
> >>
> >> It is getting better, but the issues are tough to resolve, give us
> >> another year or so :)
> > 
> > Even if it won't be possible to crash the Kernel or escalate
> > privileges, I suspect that several stuff in debugfs should never
> > be enabled on production systems, as they may reveal things like
> > memory addresses and other stuff that could be used to help someone
> > to crack a system.
> > 
> 
> Unfortunately distros enable DEBUG_FS. I checked a couple of distro configs.
> 
> One popular distro enables:
> 
> CONFIG_BLK_DEBUG_FS=y
> CONFIG_KVM_DEBUG_FS=y
> CONFIG_DEBUG_FS=y
> 
> Another one enables:
> 
> CONFIG_BLK_DEBUG_FS=y
> CONFIG_DEBUG_FS=y
> 
> It looks to me that this message need to be communicated widely so distros can
> tighten things up.

Luckily debugfs was made "root only by default" a while ago, to help
mitigate this problem.  So while it is present on a number of distros,
the "attack surface" is greatly reduced.

That being said, I bet those distros can drop those config options and
be fine.

thanks,

greg k-h