A patch that would add the last path component as a parameter to the Linux security module (LSM) hooks for inode creation raised a few eyebrows. It looked to be an attempt to add pathname-based hooks for SELinux—after many SELinux developers took strong stands against those kinds of hooks when they were proposed for AppArmor and, later, TOMOYO. But, this change would not add pathname-based access controls to SELinux, and would, instead, allow it to make decisions about the label it applies to a new inode based on the filename being created. Still, there are questions about whether this is just an ad hoc change to the LSM API for SELinux, and whether there are other hooks that might benefit from similar treatment.

The patches, which were proposed by Eric Paris on the linux-security-module mailing list, are fairly straightforward. The first simply adds a struct qstr pointer to the inode_init_security() hook and changes all the calls to it that are made, mostly in various filesystems. A qstr is a "quick string" object from the directory entry cache, which contains the filename and some additional information (length and hash). The other patch in the set changes SELinux so that it can use that information in its policies:

But the inclusion of path information was enough to get a rise out of Casey Schaufler: "I see. Pathname based controls. In SELinux.". He went on to note that AppArmor and TOMOYO had made similar arguments to Paris's and that there are already pathname-based hooks that were added to support those two solutions. But Paris is quick to point out that he is not implementing pathname-based access controls (which is what AppArmor and TOMOYO implement), but is only adding additional information for decisions about labeling new filesystem objects:

Schaufler does not completely buy that argument because of the way labels are typically maintained in an SELinux system, i.e. using user-space utilities like restorecond that are pathname-based: "Yes, the kernel component of SELinux relies strictly on the labels, but the reality is that SELinux is heavily dependent on the user space component to maintain the proper labels on files so that the specified policy is rational." Stephen Smalley agreed with that to some extent, but tries to clarify the role of pathnames in SELinux:

Smalley also explains more about the kinds of race conditions that the patch is trying to avoid:

Furthermore, Smalley said, the pathname-based hooks that are currently available in the LSM API are not usable to solve this problem because they don't address the issue of assigning labels to new inodes. The existing hooks are "about enforcing access control upon file accesses based on the pathname used to reach the file". The SELinux community has reached a consensus that the proposed change is needed, Smalley said, and the only real question in his mind was whether the changes were acceptable to the Linux virtual filesystem (VFS) and various filesystem developers.

While Schaufler recognizes that the SELinux community is fully behind the change, he wonders if there are other hooks that could also benefit from the filename information:

He goes on to point out that the LSM API is inconsistent and arbitrary, so it would make sense to look at the "bigger picture" before hacking in a change specifically for SELinux. As an example, he posits a possible access control mechanism that uses file extensions to make decisions ("only files suffixed with '.exe' can be executed and only files suffixed with '.so' can be mmapped"). Smalley believes that kind of access control could be done with the existing pathname-based hooks, but Kyle Moffett came up with another place where the filename information might be useful, even for SELinux:

The example Moffett gives would deny a compromised web application the ability to rename or link to the .htaccess file in its directories.

So far, none of the VFS or filesystem hackers have spoken up one way or another, so it is unclear whether this change will be acceptable to them. The LSM API is something of a kernel outcast—or so it appears at times—as no one is particularly satisfied with it, yet it is an integral part of the kernel security landscape. Sometimes that means that various "hacks" get added for specific security solutions, without looking at the overall picture, which is rather unfortunate. It may well be that this change is adopted, as is, without considering other potential users or consistency in the API.