debugfs: rules not welcome

Eugene Teo recently posted a request for CVE numbers for 20 separate vulnerabilities involving world-writable files in debugfs and sysfs. Some of the debugfs vulnerabilities would seemingly allow any local user to write arbitrary values into device registers - a situation from which little good can be expected to emerge. Expect yet another set of kernel updates in the near future as these holes are closed and fixes are made available to users.

In response to these vulnerabilities, Kees Cook posted a patch which would cause debugfs to be mounted with root-only access permissions. That way, any future mistakes in debugfs would be inaccessible to nonprivileged users and, thus, would not be a new vulnerability in need of fixing. The patch was not received well; it looks suspiciously like a rule in a land where there are supposed to be no rules. Greg Kroah-Hartman responded:

Kees suggested that these mistakes could keep on happening, and that "no rules" might not be the best approach, but Alan Cox responded:

There is one little problem with the idea of not mounting debugfs on production systems, though: there is useful stuff in that filesystem. At the top of the list must certainly be the control files for perf and ftrace; most of our nice, new tracing infrastructure will not work without debugfs. There are also knobs for tweaking scheduler features, interfaces for the "usbmon" tool, interfaces used by Red Hat's kvm_stat tool, and so on. There is enough useful stuff in debugfs that is it can be found mounted well outside of kernel debugging environments; it has reached the point that Greg challenges the idea that debugfs should not be mounted on production systems:

"No rules" and "mounted on enterprise systems" seems like a bad combination; it would be nice to make things more secure. A number of proposals have been floated to do that, including:

• Teach the checkpatch.pl tool to look for world-writable debugfs files and complain about them. This step has already been taken; the version of checkpatch.pl found in 2.6.38 will point out world-writable files in either debugfs or sysfs.

• Disallow world-writable files in debugfs. A patch has been posted to this effect; so far, there have been few comments to indicate whether such a restriction would look too much like a rule for debugfs or not.

• Move generally useful interfaces out of debugfs to a place with a bit less of a wild-west flavor, then leave debugfs unmounted on most systems. This is an idea which makes a lot of sense on the face of it, but it can also run into practical difficulties. Moving interfaces requires possibly cleaning them up, making a stronger commitment to ABI compatibility going forward and, importantly, breaking tools which depend on the current location of those interfaces.

The last concern could be a show stopper; it could force developers to maintain both the old and new interfaces in parallel for some years. Many developers, faced with that sort of task, may just decide to leave the interface where it is. Debugfs is not supposed to have any ABI guarantees, but, as has become clear in the past, such a policy does not necessarily prevent the creation of an ABI which must be maintained going forward.

So debugfs on production systems seems likely to be with us for some time. Given that, there is no alternative to making it more secure. The checkpatch.pl change is a good start, but it cannot take the place of proper code review. Reviewers have a tendency to skip over debugfs code, but, if that code is to run on important systems, that tendency must be fought. Debugfs code must uphold the security of the system just like any other kernel code.