From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751639AbdJCTMS (ORCPT ); Tue, 3 Oct 2017 15:12:18 -0400 Received: from sonic314-27.consmr.mail.ne1.yahoo.com ([66.163.189.153]:42832 "EHLO sonic314-27.consmr.mail.ne1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751190AbdJCTMQ (ORCPT ); Tue, 3 Oct 2017 15:12:16 -0400 X-YMail-OSG: l6PN7xAVM1kdciVu_EFoAzDJvlukDWm4SOFblj2F1tCmNBdlY32TgCrczfRXEPY I3qi4DHLkNf8lDO7cZJDzuR.RHg.sSOSihkEu6OnO7ypn7cDU1Adj0eU48jK.3HmJ2YSRGOk37HT .rkp_sbvehUzgqYpMzAb8E5Uiigtbqt7zDdJl4EeYrY4KERfc0xqUO0_jzI4rJ4OnXdUlGnhPiGb iL_oYJZNFlMPllqxfOakt_0zV63QjXG1vgeiq_G7e0erMiJ7ILCR47sulyY7TZAs857qWP7V9Vms sTk67gpBgMrhu.mznQpZpADUBqyGUM3a.RmnhZJTuKTDdpV1TCqONT6JNqfoxA0oHetcJ5DVC4KJ dKCpQhsnwGD2SyFYGkrpqUK56pjypRhmiYc.4LQX9qNb2q5NgvDs6oN6IOESbLwwN0QRhb.6ibW5 kZ6aRpcXCMkYza4HQmdyT3bxF7uaE5LRrIl8u7kjaUd18UlOa0.hIgsly.g25e0Rhld8ItSUTaEN D9MRKQb23M_BPMR6Tig-- X-Yahoo-Newman-Id: 575419.18986.bm@smtp210.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: l6PN7xAVM1kdciVu_EFoAzDJvlukDWm4SOFblj2F1tCmNBd lY32TgCrczfRXEPYI3qi4DHLkNf8lDO7cZJDzuR.RHg.sSOSihkEu6OnO7yp n7cDU1Adj0eU48jK.3HmJ2YSRGOk37HT.rkp_sbvehUzgqYpMzAb8E5Uiigt bqt7zDdJl4EeYrY4KERfc0xqUO0_jzI4rJ4OnXdUlGnhPiGbiL_oYJZNFlMP llqxfOakt_0zV63QjXG1vgeiq_G7e0erMiJ7ILCR47sulyY7TZAs857qWP7V 9VmssTk67gpBgMrhu.mznQpZpADUBqyGUM3a.RmnhZJTuKTDdpV1TCqONT6J NqfoxA0oHetcJ5DVC4KJdKCpQhsnwGD2SyFYGkrpqUK56pjypRhmiYc.4LQX 9qNb2q5NgvDs6oN6IOESbLwwN0QRhb.6ibW5kZ6aRpcXCMkYza4HQmdyT3bx F7uaE5LRrIl8u7kjaUd18UlOa0.hIgsly.g25e0Rhld8ItSUTaEND9MRKQb2 3M_BPMR6Tig-- X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- Subject: Re: [PATCH] vfs: hard-ban creating files with control characters in the name To: "Theodore Ts'o" , Adam Borowski , Al Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org References: <20171003005042.16470-1-kilobyte@angband.pl> <20171003020724.GH21978@ZenIV.linux.org.uk> <20171003164012.r4qnn5cr5kzmnft6@thunk.org> <20171003173215.axcwmd4ynmvgkyym@angband.pl> <20171003185852.2o7w4tst6q7xchfe@thunk.org> From: Casey Schaufler Message-ID: <5c29d3c0-f946-67a1-b17f-944ea1aa2c22@schaufler-ca.com> Date: Tue, 3 Oct 2017 12:12:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171003185852.2o7w4tst6q7xchfe@thunk.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > .