Messages in this thread | | | From | Mickaël Salaün <> | Subject | Re: [PATCH v1] shebang: restrict python interactive prompt/interpreter | Date | Tue, 13 Jun 2017 22:59:11 +0200 |
| |
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]
| |