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