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.do...@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/SPEC-Writing-Good-Events)
* 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
_______________________________________________
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig
