David Howells <dhowells@xxxxxxxxxx> writes: > Disallow opening of debugfs files that might be used to muck around when > the kernel is locked down as various drivers give raw access to hardware > through debugfs. Given the effort of auditing all 2000 or so files and > manually fixing each one as necessary, I've chosen to apply a heuristic > instead. The following changes are made: > > (1) chmod and chown are disallowed on debugfs objects (though the root dir > can be modified by mount and remount, but I'm not worried about that). > > (2) When the kernel is locked down, only files with the following criteria > are permitted to be opened: > > - The file must have mode 00444 > - The file must not have ioctl methods > - The file must not have mmap > > (3) When the kernel is locked down, files may only be opened for reading. > > Normal device interaction should be done through configfs, sysfs or a > miscdev, not debugfs. > Note that this makes it unnecessary to specifically lock down show_dsts(), > show_devs() and show_call() in the asus-wmi driver. > > I would actually prefer to lock down all files by default and have the > the files unlocked by the creator. This is tricky to manage correctly, > though, as there are 19 creation functions and ~1600 call sites (some of > them in loops scanning tables). Why is mounting debugfs allowed at all? Last I checked (it has been a while) the code quality of debugfs was fine for debugging but debugfs was not safe to mount on a production system. Maybe the code quality is better now but for a filesystem that is not supposed to be needed for developers letting us mount debugfs seems odd. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
