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

[Casey Schaufler <casey@schaufler-ca.com>]

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
>


.