Thread (58 messages) 58 messages, 10 authors, 2019-06-25

Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down

From: Greg KH <gregkh@linuxfoundation.org>
Date: 2019-03-27 05:33:49
Also in: linux-security-module, lkml

On Tue, Mar 26, 2019 at 10:29:41PM -0700, Andy Lutomirski wrote:
quoted
On Mar 26, 2019, at 10:06 PM, Greg KH [off-list ref] wrote:
quoted
On Tue, Mar 26, 2019 at 09:29:14PM -0700, Andy Lutomirski wrote:
quoted
On Tue, Mar 26, 2019 at 5:31 PM Greg KH [off-list ref] wrote:
quoted
On Tue, Mar 26, 2019 at 12:20:24PM -0700, Andy Lutomirski wrote:
On Tue, Mar 26, 2019 at 11:28 AM Matthew Garrett
[off-list ref] wrote:
quoted
From: Matthew Garrett <redacted>

debugfs has not been meaningfully audited in terms of ensuring that
userland cannot trample over the kernel. At Greg's request, disable
access to it entirely when the kernel is locked down. This is done at
open() time rather than init time as the kernel lockdown status may be
made stricter at runtime.
Ugh.  Some of those files are very useful.  Could this perhaps still
allow O_RDONLY if we're in INTEGRITY mode?
Useful for what?  Debugging, sure, but for "normal operation", no kernel
functionality should ever require debugfs.  If it does, that's a bug and
should be fixed.
I semi-regularly read files in debugfs to diagnose things, and I think
it would be good for this to work on distro kernels.
Doing that for debugging is wonderful.  People who want this type of
"lock down" are trading potential security for diagnositic ability.
I think you may be missing the point of splitting lockdown to separate integrity and confidentiality.  Can you actually think of a case where *reading* a debugfs file can take over a kernel?
Reading a debugfs file can expose loads of things that can help take
over a kernel, or at least make it easier.  Pointer addresses, internal
system state, loads of other fun things.  And before 4.14 or so, it was
pretty trivial to use it to oops the kernel as well (not an issue here
anymore, but people are right to be nervous).

Personally, I think these are all just "confidentiality" type things,
but who really knows given the wild-west nature of debugfs (which is as
designed).  And given that I think this patch series just crazy anyway,
I really don't care :)

thanks,

greg k-h
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help