I've finally updated PEP 558 and it's reference implementation based
on Nathaniel's feedback back in May.
The latest version of the PEP can now be found at
https://www.python.org/dev/peps/pep-0558/, and I've created a
discussion thread on Discourse:
The latest version implements Nathaniel's "independent snapshot"
proposal, and I like how that has turned out. The one thing that
changed from the May discussion thread is that the refcount semantics
of PyEval_GetLocals() (it returns a borrowed reference) meant that it
had to keep the old behaviour of returning a reference to the internal
dynamically updated shared "snapshot" at function scope, with a new
API, PyEval_GetPyLocals(), providing the C equivalent of the locals()
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
I noticed that CPython does not sanitize environment when transition between
SELinux contexts or AppArmor profiles happens, which I think is a good thing to
do in cases when one sandboxed application runs a Python script with different
(potentially less strict) sandbox configuration.
On Linux, such transition is indicated by LSMs (SELinux, AppArmor) using the
AT_SECURE bit in the aux. vector. Consult getauxval(3) in the glibc manual
for details. Here is the paragraph describing AT_SECURE:
> Has a nonzero value if this executable should be treated securely. Most
> commonly, a nonzero value indicates that the process is executing a
> set-user-ID or set-group-ID binary (so that its real and effective UIDs or
> GIDs differ from one another), or that it gained capabilities by executing a
> binary file that has capabilities (see capabilities(7)). Alternatively, a
> nonzero value may be triggered by a Linux Security Module. When this value is
> nonzero, the dynamic linker disables the use of certain environment variables
> (see ld-linux.so(8)) and glibc changes other aspects of its behavior. (See
> also secure_getenv(3).)
set-user-ID and capabilities are not directly relevant to Python since it is
not possible to apply setuid bit or file capabilities to the script (with #!).
Though, it might be relevant for other applications embedding CPython.
The case with LSMs is directly relevant for standalone scripts since both
SELinux and AppArmor allow applying per-script restrictions.
There is the -I flag for the CPython interpreter that in my opinion does
exactly what should be done when AT_SECURE bit is set. Since isolated
flag is already checked by all relevant code paths in CPython and
standard library, I believe it is a good idea to simply make AT_SECURE
imply -I. Though I am not sure whether the behavior for other
applications embedding CPython should be same.
I can put together a patch to implement that if there is an interest and
somebody can point me to an appropriate place to change.