On Sun, 2023-02-26 at 01:21 +0000, python--- via Python-ideas wrote:
Hello all,
Supply chain attacks are becoming a pressing concern in software development due to the large number of dependencies and multiple attack vectors. Using third party modules (libraries, packages etc) is always a risk but the true potential of these attacks is now being weaponized. One way to deal with the risk is by limiting access to sensitive APIs like filesystem, shell, network and ffi so that packages which aren't explicitly granted permissions cannot use them, reducing their ability to do damage.
For example, a yaml parser should not need to use ffi, network nor shell. A command line argument parser library should not use network, ffi nor filesystem. Deno, a runtime for Typescript contains an interesting implementation of a permissions model for APIs.
I strongly think Python could benefit from such functionality and hacked together a quick experiment here: https://github.com/R9295/cpython Currently, it only prevents module imports in a very elementary manner but perhaps it can be of use to spark a discussion for an implementation.
Looking forward to your thoughts, Aarnav
With the way Python is designed, this is super difficult, so good luck ;) If your use-case is when using this in production, you're likely running Linux. So, why not use seccomp[1]? libseccomp even has Python bindings[2]. This is a bit tricker to use than your proposal, as it applies limitations to the whole thread. If you want to have different limitations for your code than you have for the 3rd party one, you'll probably want to have a thread running the bits of your code that need to the unsafe syscalls (eg. fs-interaction), and have the rest of code running in a locked down thread. You just need to make sure you are not running code that originated from the protected thread in the unprotected thread, so just make sure you are not passing Python objects, even builtins like str, from the unprotected thread to the protected one. [1] https://man.archlinux.org/man/seccomp.2 [2] https://lwn.net/Articles/634391/ Cheers, Filipe Laíns