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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171006143829.GC32435@fieldses.org>
Date:   Fri, 6 Oct 2017 10:38:29 -0400
From:   "J. Bruce Fields" <bfields@...ldses.org>
To:     Dave Chinner <david@...morbit.com>
Cc:     Theodore Ts'o <tytso@....edu>, Adam Borowski <kilobyte@...band.pl>,
        Al Viro <viro@...IV.linux.org.uk>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vfs: hard-ban creating files with control characters in
 the name

On Fri, Oct 06, 2017 at 01:09:42PM +1100, Dave Chinner wrote:
> On Thu, Oct 05, 2017 at 12:16:19PM -0400, J. Bruce Fields wrote:
> > This kind of restriction sounds more like a permanent feature of the
> > filesystem--something you'd set at mkfs time.
> > 
> > We already have filesystems with these kinds of restrictions, don't we?
> 
> In general, no. Filename storage typically defined  in the
> filesystem on-disk formats as an opaque string of bytes - the
> filesystem has no business parsing them to determine validity of the
> bytes. Think encrypted filenames and the like - control characters
> in the on-disk format are most definitely necessary and therefore
> must be legal.

I was thinking of non-unixy filesystems (FAT?).

> > It'd seem trivial to add a "disallow weird characters on this
> > superblock" flag to ext4.
> 
> It seems that way until you consider the scope of work it would
> involve: to be an effective restrictive mechanism, we'd have to add
> it to the on-disk format of every supported filesystem, not just
> ext4.

Right, I was assuming it's something you'd do one filesystem at a time.

> And then, because it has become part of the defined on disk format,
> every userspace utility for each filesystem has to support it -
> mkfs, fsck, etc. Filesystem on-disk format documentation needs to be
> updated.  And checking filenames for validity under this new scheme
> and "fixing" them if they are invalid (i.e. corrupt) needs to be
> added to fsck, online scrubbers, etc. Then there's all the test
> infrastructure that is needed around this, too, so we can ensure
> that every filesystem implements the exact same semantics and
> behaviour.
> 
> And if it changes the way directories are formatted on disk for a
> filesystem, then you've got to do non-obvious stuff like /patch
> grub/ so it can parse the new format from the bootloader context.
> 
> Nothing is trivial or simple when you start needing to add
> on-disk features to filesystems...

Fair enough.

I'm not convinced it's a workable idea anyway.

But if we had to do it I'd rather see it in the filesystem just because
otherwise it's too easy for the user to create "bad" filenames (because
they mounted from a different kernel, or turned off the relevant LSM, or
whatever).  And then we get to decide whether we'd rather remap those
names somehow or fail readdir.

--b.