Hello, list. 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. -- Cheers, Max Mazurov https://foxcpp.dev _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/245DOJRXNAD6DCIS4J3EDJHDHVHW5DIF/ Code of Conduct: http://python.org/psf/codeofconduct/
