Re: PEP 551: Security transparency in the Python runtime

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.

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)

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).

> Event Log Hook
> --------------
>
> In order to achieve security transparency, an API is required to raise
> messages
> from within certain operations. These operations are typically deep within
> the
> Python runtime or standard library, such as dynamic code compilation, module
> imports, DNS resolution, or use of certain modules such as ``ctypes``.
>
> The new APIs required for log hooks are::
>
>    # Add a logging hook
>    sys.addloghook(hook: Callable[str, tuple]) -> None
>    int PySys_AddLogHook(int (*hook)(const char *event, PyObject *args));
>
>    # Raise an event with all logging hooks
>    sys.loghook(str, *args) -> None
>    int PySys_LogHook(const char *event, PyObject *args);
>
>    # Internal API used during Py_Finalize() - not publicly accessible
>    void _Py_ClearLogHooks(void);

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia