[Python-ideas] Restricting access to sensitive APIs with a permission model like Deno
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 ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/MZNP5ZJBLMUO74PMZGWJGM6TAZXBK5AS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno
Could you elaborate on how Python code can easily bypass that sort of restriction? >From my understanding, you can only do so with importlib by reading the raw >source and evaluating it. In that case, I can just restrict importlib? Same >with the open function which is from the io module which can also be >restricted (and removed from builtins in that case). Here's a diff of my implementation and upstream's 3.11.0 tag. It's 17 commits with most being README changes. I hope this makes it more clear. https://github.com/python/cpython/compare/3.11...R9295:cpython:policy Regards, Aarnav ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/NWQCBFQECB3CI3WSHSK46FTX3MAN5Z25/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno
With Python being a language heavily utilized in server and end-user applications, I would take a different approach for both. I have to admit I haven't thought much about the "normal user" in this case and focused primarily on developers. Perhaps developers shipping an application ship the code with a module policy? The way I imagine the implementation is that module restriction is recursive, so I only have to look at my top-level dependencies and not their sub-dependencies when wanting to restrict a module. Regarding the second part, I think restricting it to modules would be ideal. I also think the permissions should be like the Android model where an application can prompt you. Deno does it in an interesting manner where you can choose to be prompted, which makes sense when running an end-user application or you could reject any prompting and accept or deny the request automatically which makes sense in a server-side application. I hope this answers your questions. I am happy to elaborate if not. ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/XUVRKOELTXXEYFZAJQ7E3IRNYSDTPFVO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno
I override the import mechanism in cpython, so yes, the __import__ function is also accounted for. The sys.modules was something I had not considered, that's a good point. I will have to look into it. I am not sure how arbitrary code execution will be able to use native APIs without importing them. ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/2YUSPKDMLFVGJLPQXJ3ISJ2VDGJN7B45/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno
Thank you for the insight. I have some more work to do! I will share on this thread again when I've made further changes. If you have some time, I would be grateful if you could share a few test cases such as "bypass it by spinning off a new thread", or. object.__subclasses__. code is not necessary but just pointers. Thanks and regards, Aarnav ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/PJKPIHQT2XFF4BE2MSQ5NSSJVLR75SS2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno
Have you looked at the diff? It's not "1000+" commits as you claim. It's 17 commits with most being README changes. The base is not the master branch but the 3.11.0 release. https://github.com/python/cpython/compare/3.11...R9295:cpython:policy I do not see why you cannot audit and run this (or atleast read the code) since it's required to have a meaningful discussion, the overriding happens before the module resolution itself so sys.path is irrelevant. ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/MRUPHNBP26UDO476PSLNBTXA4YUJBHYX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno
Thank you for your insight. >I hope you are at least aware that over the years various multi-year attempts >to create Python sandboxes ultimately failed to the point of being altogether >abandoned. Yes I am, I have looked at pysandbox and RestrictedPython and I believe my approach, albeit very early stage, differs from theirs. >Besides that, the object model allows one to - sometimes not so easily, but >always consistently - bypass any write-restrictions to variables and other >memory states that would be used to restrict any access. If you have some time, could you provide me with an example or two? If I understand it correctly, only FFI would be able to do so, am I right? Regards, Aarnav ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/K6RYERRLFVWSS3RRRJSRGAIDA2XFZBDH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno
I really appreciate the pointers, thank you. I will look into them. ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/JDSYZUKU6D7GWQAOM3KQEYKIFHDYILW3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Restricting access to sensitive APIs with a permission model like Deno
Makes sense, will do so. ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/LJD7LVT7DNPRTV3MIJ2YLK4YTNKG37WQ/ Code of Conduct: http://python.org/psf/codeofconduct/
