Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753742AbdFMVog (ORCPT ); Tue, 13 Jun 2017 17:44:36 -0400 Received: from nm27.bullet.mail.ne1.yahoo.com ([98.138.90.90]:60173 "EHLO nm27.bullet.mail.ne1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752452AbdFMVoe (ORCPT ); Tue, 13 Jun 2017 17:44:34 -0400 X-Yahoo-Newman-Id: 507370.36606.bm@smtp114.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: TPvDnNUVM1nJkMZUxr4fN_EdzDeBmTrGshwYYvjZ5h5j0og FTYnCk9s_97KT8l569_YCEOiDw6drOQrz0OAb81_5hq6suWQGka6ytws.u3y qM46PyWDCWDZLSZ3RaX28SBxXkzJtf8Kc1yAeVORBjIjnKT7aR62ddHNeTqJ w7VwfSsPOo4xcrtuSQ9kfu8QdgN4k0GPDFNgkAuhF_kHzTLGSwZsgH9bedxT mc1Erq8TaV69fk8JtDlrnG0htXDzVdfRyk8U1Q19xLsSHnxrxgXBQymQyK.O Gg7eYiVG9kRgQGRW98kOO5g6g9Nh3Yk1p2468oImYvs94Hh3WP2Uw2y56JPG vhfjCNhXdiOXv3CgMP0Lbn3TPsQJL0wTYrAufltd86R2x_07nymlBdYIyQXc Ax6nSpZtyPd_yjig2PkE7VypueAu8Z9uXeTDeoFQ_OL6nQ2kxLIiG76SrvGa IQTAZe_MuXrA0BzQ1TdVBmGT21dqRvpK9qsVq4Wkk_jIDiAq4wVMkzStepWr Ww_a3Wu1TiFlQujONVmW4kSHZJqyX6DW43xq8gMOBhze2lfguPV6O4GKjZjK S.qB4NXO_iuWEHrXTYHVCtOGU X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- Subject: Re: [kernel-hardening] Re: [PATCH v1] shebang: restrict python interactive prompt/interpreter To: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= , Mimi Zohar , Tetsuo Handa , keescook@chromium.org, matt@nmatt.com Cc: jason@perfinion.com, linux-security-module@vger.kernel.org, Daniel Micay , kernel-hardening , LKML References: <201706100041.GFH78616.OFtOHFJSLQOMVF@I-love.SAKURA.ne.jp> <754b78d1-f7f9-58bd-bf74-fea9e105649a@nmatt.com> <20170609164315.GA1141@meriadoc.perfinion.com> <201706101427.EEG90168.OtFFHSFMOVOJQL@I-love.SAKURA.ne.jp> <1497234757.21594.280.camel@linux.vnet.ibm.com> <8a2300ef-1462-0e1f-2d6a-81e6020bc71f@digikod.net> From: Casey Schaufler Message-ID: <9564a13e-3007-4cd8-5c7f-7127333da93f@schaufler-ca.com> Date: Tue, 13 Jun 2017 14:44:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <8a2300ef-1462-0e1f-2d6a-81e6020bc71f@digikod.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3291 Lines: 58 On 6/13/2017 1:59 PM, Mickaël Salaün wrote: > On 12/06/2017 04:32, Mimi Zohar wrote: >> On Sun, 2017-06-11 at 13:44 +0200, Mickaël Salaün wrote: >>> On 10/06/2017 07:27, Tetsuo Handa wrote: >>>> Kees Cook wrote: >>>>> On Fri, Jun 9, 2017 at 10:23 AM, Matt Brown wrote: >>>>>> what does everyone thing about a envp_blacklist option that is a list of >>>>>> environmental variables that will be stripped from exec calls. This can >>>>>> be done in the LSM hook bprm_check_security. >>>>>> >>>>>> Is there any reason on a hardened system why you would need the >>>>>> PYTHONINSPECT environmental variable? >>>>> As part of shebang, it likely makes sense to whitelist (rather than >>>>> blacklist) the env of the restricted interpreters. Though this is >>>>> starting to get complex. :P >>>> Blacklisting environment variables is dangerous. I think that >>>> administrators can afford whitelisting environment variable names. >>>> I think that implementing whitelist of environment variable names >>>> as an independent LSM module would be fine. >>>> >>>> While it is true that things starts getting complex if we check environment >>>> variables, shebang will already become complex if it starts worrying about >>>> updating inode number list in order to close the race window between doing >>>> creat()+write()+close()+chmod()+rename() by the package manager and teaching >>>> the kernel the new inode number determined by creat(). We will need an >>>> interface for allowing the package manager to teach the kernel the new inode >>>> number and modification of the package manager, for the kernel side is doing >>>> inode number based blacklisting while user side can execute it before rename(). >> I don't think we're trying to protect against executing the >> interpreter prior to the rename. Rename, itself, would trigger >> associating the interpreter name with an inode number. >> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in >>>> the body of a message to majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>> >>> Using filesystem xattr seems like a good idea for this kind of >>> exceptions and instead of a hardcoded interpreter path. Something like >>> "security.tpe.interpreter=1|2" (bitmask for interpreter-only and/or CLI) >>> and "security.tpe.environment=HOME,LOGNAME" would be quite flexible to >>> configure a security policy for some binaries. This could also be >>> protected by IMA/EVM, if needed. >> Checking for the existence of an xattr without caching is relatively >> slow. I'm not sure that we would want to go this route. >> >>> This kind of xattr should be writable by the owner of the file. The TPE >>> LSM [1] could then take these xattr into account according to the TPE >>> policy. >> Security xattrs are only writable by root. > This is currently the case but an exception for this kind of LSM could > be allowed, or another dedicated prefix could be used. Better yet, use "user.tpe.whatever" and explicitly look for that in your xattr hooks, denying access based on whatever criteria you like. You could allow it to be set, but never deleted, for example. You can do it all within shebang without creating exceptions or new prefixes.