Messages in this thread | | | Subject | Re: [PATCH v1] shebang: restrict python interactive prompt/interpreter | From | Mickaël Salaün <> | Date | Sun, 11 Jun 2017 13:44:22 +0200 |
| |
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(). > -- > 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.
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
[unhandled content-type:application/pgp-signature]
| |