Re: PEP 551: Security transparency in the Python runtime

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 <steve.dower@python.org> 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/S...)
> * 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