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 12:12:08 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     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 10/3/2017 11:58 AM, Theodore Ts'o wrote:
> 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.

The resistance to using LSMs for things other than access control
is pretty well gone at this point. An LSM implementation makes sense,
and I'm pretty sure I saw one proposed recently. I can't find the
details, unfortunately. 

>
>       	      	      	     	 - Ted
>


.