On 24Aug2017 2317, Nick Coghlan wrote:
Migrating my comments from Twitter :)
I really like this PEP as a way of enabling runtime hardening of platform-integrated Python builds, without tightly coupling upstream development to the evolution of the related platform security APIs, so a big +1 from me for the general idea.
Thanks!
On 25 August 2017 at 03:13, Steve Dower
wrote: On Linux, some specific features that may be integrated are:
* gnupg [8]_ * sd_journal [9]_ * OpenBSM [10]_ * syslog [11]_ * check execute bit on imported modules
A couple more references/integration ideas:
* emitting Linux audit log events (https://github.com/linux-audit/audit-documentation/wiki/SPEC-Writing-Good-Ev...) * restricting imports and code execution to files with appropriate SELinux labels (e.g. defining a "py_exec_t" type and checking that in open_for_exec)
Nice. I looked into SELinux and didn't find any docs about how to add labels. I'd really like to include links that help people actually implement this stuff - any tips?
We wouldn't be able to do this kind of thing to /usr/bin/python3 without breaking the world, but there's more scope for making changes to private installations like Fedora's /usr/libexec/platform-python (see https://fedoraproject.org/wiki/Changes/Platform_Python_Stack - we're not going to migrate everything to use that, but we *do* want to get to the point where that's the only Python available in a minimal Fedora install, which means migrating at least dnf/yum and the associated plugins).
Yep, that's the use case, though auditing /usr/bin/python3 shouldn't inherently break anything. Actually aborting operations or restricting imports in any way only makes sense in a fully (or mostly) controlled environment.
Bikeshed: to more clearly distinguish this proposal from regular logging module events, I'd suggest calling these audit hooks rather than log hooks. I also think this could be a separate module at the Python level (e.g. "runtimeaudit"), and a separate prefix at the C API level (e.g. "PyAudit_*") rather than needing to be directly in the sys namespace.
+1 on "audit hooks" - I'll change to that when I do my next pass. But -1 on having the separate module and -0 on "PyAudit_*" (as a result of it not being in its own module). It's important to minimise the surface area of these features, and having the ability to disable auditing by shadowing/replacing a module is a little scary. At least when you replace sys you've got to do a bit of work to keep it a secret. (This is also the reasoning for using static variables internally rather than interpreter state - it's much harder to infer the address of a static C variable with pure Python code than a field in a struct.) Though as long as the replacement itself triggers an auditable event, regardless of subsequent events, we have been successful. Currently though, `sys.modules['audit'] = SomethingElse` is not audited (and likely not trivial - of course, that doesn't block this PEP, but it remains as a future possibility for someone who wants to make it happen). Cheers, Steve