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]

Date:   Tue, 3 Oct 2017 14:58:52 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Adam Borowski <kilobyte@...band.pl>
Cc:     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 Tue, Oct 03, 2017 at 07:32:15PM +0200, Adam Borowski wrote:
> 
> 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.

If we look at the attitude used by the kernel-hardening efforts, it's
all about adding layers of protection.  We can optionally enable
features like KASLR, but does that mean that people can afford to be
careless with pointers?  Not hardly!

And that's a pretty good worked example where adding various classes
of kernel-hardening protections has *not* resulted in people saying,
"Great!  I can be careless in the patches we submit to LKML".

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

I would have suggested 1-31, since that's in line with what Windows
has banned.  But whether we include DEL is my mind not a big deal.

The argument for making it be configurable is that if it does break
things in way we can't foresee, it's a lot easier to back it out.  And
like what we've done with relatime, if the distro's all run with it as
the default for a couple of years, it then becomes easier to make the
case for making it be the default.

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

Perhaps doing this as an LSM makes the most amount of sense.  That
makes it be configurable/optional, and I think the security folks will
be much more willing to accept the functionality, if we decide we
don't want to make it a core VFS restriction.

      	      	      	     	 - Ted