Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down
On Wed, Mar 27, 2019 at 10:39:53AM -0700, Andy Lutomirski wrote: > On Tue, Mar 26, 2019 at 10:33 PM Greg KH wrote: > > > > On Tue, Mar 26, 2019 at 10:29:41PM -0700, Andy Lutomirski wrote: > > > > > > > > > > On Mar 26, 2019, at 10:06 PM, Greg KH > > > > wrote: > > > > > > > >> On Tue, Mar 26, 2019 at 09:29:14PM -0700, Andy Lutomirski wrote: > > > >>> On Tue, Mar 26, 2019 at 5:31 PM Greg KH > > > >>> wrote: > > > >>> > > > On Tue, Mar 26, 2019 at 12:20:24PM -0700, Andy Lutomirski wrote: > > > On Tue, Mar 26, 2019 at 11:28 AM Matthew Garrett > > > wrote: > > > > > > > > From: Matthew Garrett > > > > > > > > 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 :) > > > > As far as I'm concerned, preventing root from crashing the system > should not be a design goal of lockdown at all. And I think that the > "integrity" mode should be as non-annoying as possible, so I think we > should allow reading from debugfs. Sorry, the "crash the system" is not the issue here. The issue is if everyone can "ensure" that "everything" in debugfs is "safe" for this mode of "lock down". Given that no one has any idea of what really is in debugfs, and to try to compare that with the design goals of what "lock down" really is trying to achive, I think the goal of just giving up and restricting access is fine if that makes people feel better about this whole thing. If this is locked down, it is going to cause distros more pain in debugging user's issues, but that's their choice, not mine :) thanks, greg k-h
Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down
On Wed, Mar 27, 2019 at 10:42:18AM -0700, Matthew Garrett wrote: > On Wed, Mar 27, 2019 at 10:40 AM Andy Lutomirski wrote: > > As far as I'm concerned, preventing root from crashing the system > > should not be a design goal of lockdown at all. And I think that the > > "integrity" mode should be as non-annoying as possible, so I think we > > should allow reading from debugfs. > > I have no horse in this game - I'm happy to bring back the previous > approach for integrity mode and block reads entirely in > confidentiality mode, but I'd rather not spend another release cycle > arguing about it. I really do not care either way about any of this :) greg k-h
Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down
On Wed, Mar 27, 2019 at 10:40 AM Andy Lutomirski wrote: > As far as I'm concerned, preventing root from crashing the system > should not be a design goal of lockdown at all. And I think that the > "integrity" mode should be as non-annoying as possible, so I think we > should allow reading from debugfs. I have no horse in this game - I'm happy to bring back the previous approach for integrity mode and block reads entirely in confidentiality mode, but I'd rather not spend another release cycle arguing about it.
Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down
On Tue, Mar 26, 2019 at 10:33 PM Greg KH wrote: > > On Tue, Mar 26, 2019 at 10:29:41PM -0700, Andy Lutomirski wrote: > > > > > > > On Mar 26, 2019, at 10:06 PM, Greg KH wrote: > > > > > >> On Tue, Mar 26, 2019 at 09:29:14PM -0700, Andy Lutomirski wrote: > > >>> On Tue, Mar 26, 2019 at 5:31 PM Greg KH > > >>> wrote: > > >>> > > On Tue, Mar 26, 2019 at 12:20:24PM -0700, Andy Lutomirski wrote: > > On Tue, Mar 26, 2019 at 11:28 AM Matthew Garrett > > wrote: > > > > > > From: Matthew Garrett > > > > > > 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 :) > As far as I'm concerned, preventing root from crashing the system should not be a design goal of lockdown at all. And I think that the "integrity" mode should be as non-annoying as possible, so I think we should allow reading from debugfs.
Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down
On Wed, 27 Mar 2019, Greg KH wrote: > 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 :) Why do you think it's crazy? -- James Morris
Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down
On Tue, Mar 26, 2019 at 10:29:41PM -0700, Andy Lutomirski wrote: > > > > On Mar 26, 2019, at 10:06 PM, Greg KH wrote: > > > >> On Tue, Mar 26, 2019 at 09:29:14PM -0700, Andy Lutomirski wrote: > >>> On Tue, Mar 26, 2019 at 5:31 PM Greg KH > >>> wrote: > >>> > On Tue, Mar 26, 2019 at 12:20:24PM -0700, Andy Lutomirski wrote: > On Tue, Mar 26, 2019 at 11:28 AM Matthew Garrett > wrote: > > > > From: Matthew Garrett > > > > 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
Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down
> On Mar 26, 2019, at 10:06 PM, Greg KH wrote: > >> On Tue, Mar 26, 2019 at 09:29:14PM -0700, Andy Lutomirski wrote: >>> On Tue, Mar 26, 2019 at 5:31 PM Greg KH wrote: >>> On Tue, Mar 26, 2019 at 12:20:24PM -0700, Andy Lutomirski wrote: On Tue, Mar 26, 2019 at 11:28 AM Matthew Garrett wrote: > > From: Matthew Garrett > > 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?
Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down
On Tue, Mar 26, 2019 at 09:29:14PM -0700, Andy Lutomirski wrote: > On Tue, Mar 26, 2019 at 5:31 PM Greg KH wrote: > > > > On Tue, Mar 26, 2019 at 12:20:24PM -0700, Andy Lutomirski wrote: > > > On Tue, Mar 26, 2019 at 11:28 AM Matthew Garrett > > > wrote: > > > > > > > > From: Matthew Garrett > > > > > > > > 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. good luck! greg k-h
Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down
On Tue, Mar 26, 2019 at 5:31 PM Greg KH wrote: > > On Tue, Mar 26, 2019 at 12:20:24PM -0700, Andy Lutomirski wrote: > > On Tue, Mar 26, 2019 at 11:28 AM Matthew Garrett > > wrote: > > > > > > From: Matthew Garrett > > > > > > 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.
Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down
On Tue, Mar 26, 2019 at 07:06:36PM -0700, Matthew Garrett wrote: > On Tue, Mar 26, 2019 at 5:31 PM Greg KH wrote: > > On Tue, Mar 26, 2019 at 11:27:41AM -0700, Matthew Garrett wrote: > > > From: Matthew Garrett > > > > > > 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. > > (snip) > > > Why allow all this, why not just abort the registering of the filesystem > > with the vfs core so it can't even be mounted? > > As mentioned in the commit message, because the lockdown state can be > made stricter at runtime - blocking at mount time would be > inconsistent if the machine is locked down afterwards. We could > potentially assert that it's the admin's responsibility to ensure that > debugfs isn't mounted at the point of policy being made stricter? Ugh, I can not read, sorry, neverind. The patch is fine as-is. greg k-h
Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down
On Tue, Mar 26, 2019 at 5:31 PM Greg KH wrote: > On Tue, Mar 26, 2019 at 11:27:41AM -0700, Matthew Garrett wrote: > > From: Matthew Garrett > > > > 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. (snip) > Why allow all this, why not just abort the registering of the filesystem > with the vfs core so it can't even be mounted? As mentioned in the commit message, because the lockdown state can be made stricter at runtime - blocking at mount time would be inconsistent if the machine is locked down afterwards. We could potentially assert that it's the admin's responsibility to ensure that debugfs isn't mounted at the point of policy being made stricter?
Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down
On Tue, Mar 26, 2019 at 11:27:41AM -0700, Matthew Garrett wrote: > From: Matthew Garrett > > 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. > > Signed-off-by: Matthew Garrett > Cc: gre...@linuxfoundation.org > --- > fs/debugfs/file.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c > index 4fce1da7db23..9ae12ef29ba0 100644 > --- a/fs/debugfs/file.c > +++ b/fs/debugfs/file.c > @@ -142,6 +142,9 @@ static int open_proxy_open(struct inode *inode, struct > file *filp) > const struct file_operations *real_fops = NULL; > int r; > > + if (kernel_is_locked_down("debugfs", LOCKDOWN_INTEGRITY)) > + return -EPERM; Why allow all this, why not just abort the registering of the filesystem with the vfs core so it can't even be mounted? thanks, greg k-h
Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down
On Tue, Mar 26, 2019 at 12:20:24PM -0700, Andy Lutomirski wrote: > On Tue, Mar 26, 2019 at 11:28 AM Matthew Garrett > wrote: > > > > From: Matthew Garrett > > > > 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. thanks, greg k-h
Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down
On Tue, Mar 26, 2019 at 12:20 PM Andy Lutomirski wrote: > Ugh. Some of those files are very useful. Could this perhaps still > allow O_RDONLY if we're in INTEGRITY mode? The previous implementation did, but Greg wanted it to go away entirely.
Re: [PATCH V31 25/25] debugfs: Disable open() when kernel is locked down
On Tue, Mar 26, 2019 at 11:28 AM Matthew Garrett wrote: > > From: Matthew Garrett > > 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?
[PATCH V31 25/25] debugfs: Disable open() when kernel is locked down
From: Matthew Garrett 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. Signed-off-by: Matthew Garrett Cc: gre...@linuxfoundation.org --- fs/debugfs/file.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c index 4fce1da7db23..9ae12ef29ba0 100644 --- a/fs/debugfs/file.c +++ b/fs/debugfs/file.c @@ -142,6 +142,9 @@ static int open_proxy_open(struct inode *inode, struct file *filp) const struct file_operations *real_fops = NULL; int r; + if (kernel_is_locked_down("debugfs", LOCKDOWN_INTEGRITY)) + return -EPERM; + r = debugfs_file_get(dentry); if (r) return r == -EIO ? -ENOENT : r; @@ -267,6 +270,9 @@ static int full_proxy_open(struct inode *inode, struct file *filp) struct file_operations *proxy_fops = NULL; int r; + if (kernel_is_locked_down("debugfs", LOCKDOWN_INTEGRITY)) + return -EPERM; + r = debugfs_file_get(dentry); if (r) return r == -EIO ? -ENOENT : r; -- 2.21.0.392.gf8f6787159e-goog