Re: [PATCH] vfs: hard-ban creating files with control characters in the name

[Theodore Ts'o <tytso@mit.edu>]

On Fri, Oct 06, 2017 at 07:57:01AM -0700, Matthew Wilcox wrote:
> 
> Umm.  But filenames still can't have / or \0 in them, so your encryption
> already has to avoid at least two special characters.
> 
> I agree with your main point though; there is no advantage to doing this
> in each individual filesystem.

One advantage of doing it in an LSM is you can simply make this a ban
on the *creation* of new files that match some particular "bad
character set".  This might be all characters between 1 and 31, not
just for security reasons, but also if you are running a filer where
the files need to be accessible by Windows sytems, and Windows doesn't
allow file names containing control characters.

Ultimately, the cost/benefit ratio of this is small.  Forbidding
newlines doesn't actually buy you that much.  It is true that there
are some shell progamming constructs which will deal with embedded
spaces in file names, but not with embedded newlines --- but there are
many more constructs that will fail to deal with spaces, and there
enough other potential gotchas that if a shell script progammer isn't
using something like shellcheck, they are going to be tempting fate.

At the same time, the _cost_ of forbidding control chracaters is tiny.
And while the risk of embedding an entertaining escape sequence into a
filename and waiting for a root user to list the directory is low ---
what's the likelihood we will be crimping a user or shell script's
style by forbidding the escape sequence in a filename?

Most of these problems are really only an issue on time-sharing
systems, so for people who are worried about these attacks --- they
can enable an LSM, just as people who are willing to deal with the
pain of SELinux can enable SELinux.  :-)

					- Ted