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

From: Adam Borowski <kilobyte@angband.pl>
To: "Theodore Ts'o" <tytso@mit.edu>,
	Al Viro <viro@ZenIV.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vfs: hard-ban creating files with control characters in the name
Date: Tue, 3 Oct 2017 19:32:15 +0200	[thread overview]
Message-ID: <20171003173215.axcwmd4ynmvgkyym@angband.pl> (raw)
In-Reply-To: <20171003164012.r4qnn5cr5kzmnft6@thunk.org>

On Tue, Oct 03, 2017 at 12:40:12PM -0400, Theodore Ts'o wrote:
> On Tue, Oct 03, 2017 at 03:07:24AM +0100, Al Viro wrote:
> > That essay is full of shit, and you've even mentioned parts of that just above...
> > NAK; you'd _still_ need proper quoting (or a shell with something resembling an
> > actual syntax, rather than the "more or less what srb had ended up implementing"),
> > so it doesn't really buy you anything.  Badly written script will still be
> > exploitable.  And since older kernels and other Unices are not going away,
> > you would've created an inconsistently vulnerable set of scripts, on top of
> > the false sense of security.
> 
> Banning certain characters is certainly not a panacea, and there are a
> lot of best practices that you have to follow when writing good
> scripts which most people don't follow, and so it's arguable that
> benefits are being overstated.

Yeah, it's "most people don't follow" which is the main issue here.  And
it appears to me that it's easy to plug the worst issues, especially \n.

> That being said the costs of suppressing certain bytes from appearing
> in pathnames seem fairly low.

There are three categories of problematic bytes/byte sequences:
* those that don't appear in the wild, require a bit of knowledge to input
  (inserting a control char is no rocket science but is beyond an average
  user's skill), and also have potential to cause damage
  - This is why I picked 1-31,127 in the initial patch.
* stuff that's unwanted but not unknown in the wild
* stuff that's used by every "normal" user, and considered problematic only
  by us traditional Unix folks

> Would this be more palatable if the ban on control characters were made
> into a compile-time or mount-time option?

For malformed Unicode or such, it'd make sense, yeah.

But Al has a good point that if most people were protected, they won't
bother escaping badness anymore -- leaving those whose systems allow control
chars vulnerable if they run a script that doesn't do quoting.

Thus, it'd be good to make at least worst cases non-configurable.

I went bold and submitted 1-31,127, as those have very low cost to block;
but if that's not conservative enough, blocking just \n has both very low
cost and a high benefit (special burdensome quoting required).

Discussing a configurable policy (perhaps here in vfs, perhaps as a LSM, a
seccomp hack or even LD_PRELOAD) would be interesting, but for the above
reason I'd want \n hard-banned.

Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄⠀⠀⠀⠀ agriculture, towns then cities.     -- whitroth on /.