lkml.org 
[lkml]   [2017]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v1] shebang: restrict python interactive prompt/interpreter
Date

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 <matt@nmatt.com> 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.

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2017-06-13 23:00    [W:0.079 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site