linux-kernel - Re: [PATCH v1] shebang: restrict python interactive prompt/interpreter

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-next>] [day] [month] [year] [list]

Date:   Sun, 11 Jun 2017 13:44:22 +0200
From:   Mickaël Salaün <mic@...ikod.net>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        keescook@...omium.org, matt@...tt.com
Cc:     jason@...finion.com, zohar@...ux.vnet.ibm.com,
        linux-security-module@...r.kernel.org,
        Daniel Micay <danielmicay@...il.com>,
        kernel-hardening <kernel-hardening@...ts.openwall.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] shebang: restrict python interactive
 prompt/interpreter


On 10/06/2017 07:27, Tetsuo Handa wrote:
> Kees Cook wrote:
>> On Fri, Jun 9, 2017 at 10:23 AM, Matt Brown <matt@...tt.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().
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@...r.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.

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.

The "security.tpe.environment" could also be set on a script file to be
part of the union with the interpreter's environment whitelist. This may
be needed to be able to use environment variables as configuration in a
script.

In the future, a "security.tpe.memory" could contain a set of flags as
PaX uses for mprotect-like exceptions (user.pax.flags).

Userland daemons such as paxctld or paxrat could be used (with some
tweaks) to keep a consistent TPE policy over time.

 Mickaël


[1] https://lkml.kernel.org/r/1497015878.21594.201.camel@linux.vnet.ibm.com



Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)