There are few restrictions on file names in Linux—essentially just two: no "/" and no "/0"—but that freedom can lead to various problems, including security problems. Vulnerabilities like arbitrary file deletion and denial of service have resulted from programs mishandling file names with unexpected characters, for example. Most users and administrators do not use file names with control characters or other oddities, to the point where some may not even realize it is possible to construct such file names. Protecting those users from these kinds of unexpected problems and vulnerabilities is the target of the Safename Linux security module (LSM) that is beingproposed by David A. Wheeler.

There are a myriad of ways that file names can go "wrong" on Linux. Consider a file name that begins with a "-"; if that name ends up on the command line (perhaps via a shell glob pattern), the file could be interpreted as command-line switch. File names containing newlines or other control characters can also lead to unexpected results—and output. Beyond that, file names that are illegal in the system encoding (e.g. UTF-8) cannot be displayed sensibly.

The problems that come from unexpected file names are described on a web page that Wheeler maintains. On that page, he suggests that allowing system administrators to restrict the kinds of file names that can be created would alleviate a whole raft of problems. Safename would provide a mechanism to do just that.

As Wheeler notes on that page (and in the patches), POSIX defines "portable" file names that are quite a bit more restrictive (only ASCII alphanumeric characters, period, underscore, and hyphen if it is not the first character of the name). Other operating systems and some filesystems on Linux already impose more restrictions on file names, including disallowing space and control characters or mandating a particular encoding.

There have been security vulnerabilities caused by unexpected file names, including a denial of service in logrotate caused by newlines or backslashes in file names ( CVE-2011-1155 ) and a remote arbitrary file deletion vulnerability in uscan caused by white-space characters in file names ( CVE-2013-7085 ). Undoubtedly, others lurk in various programs, but the bigger problem is probably contained in scripts and other "one-off" programs that administrators write to solve a problem quickly—without considering the ways that "strange" file names can result in bugs, especially when run on user-controlled directories.

In the patch posting, Wheeler outlines three ways that these potentially dangerous file names might come about. A malicious user or application could directly create a file that is then used by some other non-malicious application leading to an exploit. Or a non-malicious, unprivileged application could be tricked by an attacker into creating a dangerous file name, which could then lead to an exploit when some non-malicious, but buggy, script or program uses the file. Similarly, a privileged application could be tricked into creating one of these file names, which could lead to an exploit when some other code handles the file name—which means that administrators may want a way to stop even privileged code from creating them.

Safename will help administrators avoid these kinds of problems by restricting the kinds of file names that can be created. Notably, it does not enforce any restrictions on existing file names, though that could be added as an (expensive) operation at mount time. It uses the LSM hooks for any operation that can create a new file name (file creation, hard or symbolic link creation, rename, and directory or special-file creation) and enforces a set of restrictions on them.

The behavior of Safename is governed by a number of control files that are currently under /proc/sys/kernel/safename , but will be moving /sys/fs/safename based on asuggestion from Casey Schaufler. Enabling the feature for unprivileged users is done using the mode_for_unprivileged file, while privileged users’ file name creation is governed by mode_for_privileged . Currently, "privileged" means has CAP_SYS_ADMIN , though that will change to CAP_MAC_ADMIN , which was also suggested by Schaufler since it is less likely to be given to a process for other purposes ( CAP_SYS_ADMIN is something of a catch-all).

There are two settings available that can be combined and written to the two mode files. They are implemented as two bits that govern whether the rules are enforced and whether illegal file names are logged (using printk_ratelimited() ). The low-order bit is for the enforcement setting and the other is for the logging setting. So, zero means no enforcement or logging, one is for enforcement without logging, two for logging without enforcement, and three for both actions. For both modes, the default value is zero, which means no enforcement and no reporting (effectively the same as a kernel running without the module loaded).

In addition, there are configuration files to alter the rules for file names. The boolean utf8 file governs whether the file names must be valid UTF-8; it defaults to zero, which turns off UTF-8 checking. There are also three files that govern the character values allowed in various parts of the file name: first character, last character, and the characters in between. Those files are:

permitted_bytes_initial : The permitted set of characters for the first byte of the file name, the default is 33-44,46-125,128-254, which omits control characters, space, hyphen, tilde, delete (0x7f), and 0xff.

permitted_bytes_middle : The permitted set for the characters of the file name that are not the first or last (so file names of one or two characters are not subject to these requirements). By default, the value is 32-126,128-254, which leaves out control characters, delete, and 0xff.

permitted_bytes_final : The set of characters allowed for the last byte of a file name (a one-character file name must pass the initial and final tests). The default is 33-126,128-254, which removes control characters, space, delete, and 0xff.

Any attempt to create a file name that fails the tests will be rejected with an EPERM error, though Schaufler pointed out that EINVAL

might be a better choice.

The comments on the patches have been fairly sparse to date, but the proposal is an indicator that the security module stacking feature is leading to more special-purpose LSMs being developed. When the single LSM slot was generally occupied by one of the monolithic LSMs (e.g. SELinux, AppArmor, Smack), there was little point in creating smaller modules that catered to a specific security concern. With the ability to add multiple LSMs that came with module stacking, efforts likeLoadPin and Safename will be able to offer specialized tools for administrators who want them.