All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adam Borowski <kilobyte@angband.pl>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: 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 05:22:03 +0200	[thread overview]
Message-ID: <20171003032203.6ufi7cmsgu47mrke@angband.pl> (raw)
In-Reply-To: <20171003020724.GH21978@ZenIV.linux.org.uk>

On Tue, Oct 03, 2017 at 03:07:24AM +0100, Al Viro wrote:
> On Tue, Oct 03, 2017 at 02:50:42AM +0200, Adam Borowski wrote:
> > Anything with bytes 1-31,127 will get -EACCES.
> > 
> > Especially \n is bad: instead of natural file-per-line, you need an
> > user-unfriendly feature of -print0 added to every producer and consumer;
> > a good part of users either don't know or don't feel the need to bother
> > with escaping this snowflake, thus introducing security holes.
> > 
> > The rest of control characters, while not as harmful, don't have a
> > legitimate use nor have any real chance of coming from a tarball (malice
> > and fooling around excluded).  No character set ever supported as a system
> > locale by glibc, and, TTBMK, by other popular Unices, includes them, thus
> > it can be assumed no foreign files have such names other than artificially.
> > 
> > This goes in stark contrast with other characters proposed to be banned:
> > non-UTF8 is common, and even on my desktop's disk I found examples of all
> > of: [ ], < >, initial -, initial and final space, ?, *, .., ', ", |, &.
> > Somehow no \ anywhere.  I think I have an idea why no / .
> > 
> > Another debatable point is whether to -EACCES or to silently rename to an
> > escaped form such as %0A.  I believe the former is better because:
> > * programs can be confused if a directory has files they didn't just write
> > * many filesystems already disallow certain characters (like invalid
> >   Unicode), thus returning an error is consistent
> > 
> > An example of a write-up of this issue can be found at:
> > https://www.dwheeler.com/essays/fixing-unix-linux-filenames.html
> 
> That essay is full of shit, and you've even mentioned parts of that just
> above...

I used it as a list of problems, not solutions.

> 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.

Well, what about just \n then?  Unlike all the others which are relatively
straightforward, \n requires -print0 which not all programs implement, and
way too many people consider too burdensome to use.

> Badly written script will still be exploitable.

Yeah, but we'd kill a major exploit avenue.

> 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.

That shouldn't stop us from improving new kernels -- scripts that have
-print0 won't lose it, those that don't will have a vulnerability fixed. 
Same as with any other kind of hardening.  As for other Unices: Theo de
Raadt is not someone to object to a trivial security patch, FreeBSD would
follow, OSX is too hostile to developers for me to care.  Thus, the only
concern is new userland on old kernels.  But distributions don't support
such combinations for long, unlike the other way around.  As for people
writing their own scripts: they already tend to be vulnerable.

I for example, when writing an ad-hoc pipeline, tend to first make it
display files that'd be processed; switching that to -print0 back and forth
would be really tedious thus I usually remain vulnerable to \n (unless the
script is meant for external use -- but it's too easy to forget).  And how
do you propose to process a list of files with grep or sed if there are
newlines involved?

Basic quotes make it trivial to handle everything but two snowflakes: \n and
initial -; the latter you need to remember about but ./* or -- aren't hard.
This leaves \n.

Thus, would you consider banning just newlines?


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 /.

  reply	other threads:[~2017-10-03  3:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-03  0:50 [PATCH] vfs: hard-ban creating files with control characters in the name Adam Borowski
2017-10-03  2:07 ` Al Viro
2017-10-03  3:22   ` Adam Borowski [this message]
2017-10-05 10:07     ` Olivier Galibert
2017-10-06 14:54       ` Matthew Wilcox
2017-10-03 16:40   ` Theodore Ts'o
2017-10-03 17:32     ` Adam Borowski
2017-10-03 18:58       ` Theodore Ts'o
2017-10-03 19:12         ` Casey Schaufler
2017-10-05 16:16         ` J. Bruce Fields
2017-10-06  2:09           ` Dave Chinner
2017-10-06 14:38             ` J. Bruce Fields
2017-10-06 14:57             ` Matthew Wilcox
2017-10-06 20:00               ` Theodore Ts'o
2017-10-08 22:03               ` Dave Chinner
2017-10-05 13:47       ` Alan Cox
2017-10-05 12:07 Alexey Dobriyan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171003032203.6ufi7cmsgu47mrke@angband.pl \
    --to=kilobyte@angband.pl \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.