On 26Aug2017 1018, Christian Heimes wrote:
On 2017-08-26 15:45, Brett Cannon wrote:
Is there going to be a visible flag or anything to know you're running a restricted version of Python? If so then a subclass will allow us to override get_code() so that it just skips .pyc files and it can be used automatically when the flag is set. That way users of spython don't have to think about setting that up. Otherwise we could provide a function in importlib._bootstrap that you call during initialization to turn this on.
We should add a new attribute to sys.flags, e.g. sys.flags.restricted.
When would the flag be enabled? Currently my proposed changes are available all the time, and by design there's no way to know whether calls to PySys_LogHook() or open_for_exec() have been hooked or not. If it can be optionally enabled by the entry point (i.e. spython.c enables it but python.c does not), then that would make sense, but I'd have to recommend that entry points should probably not set it unless they want to reveal that they're auditing the process :)
In fact there should be two new flags. We need a way to prevent interactive Python shells like cmd module and pdb interactive mode. After all we want to prevent hackers from getting access to an interactive Python prompt. The cmd module implements such an interactive command interpreter.
The only reliable way to do this is to remove the modules when you deploy to production. Otherwise, the best protection is the fact that your code that imports and starts them has already gotten past open_for_exec() and whatever your import and compile hooks do (malware scan, blocklist, etc.). Also, interactive prompts are only really used so that attackers can pipe code into stdin. If someone is already interactive on your box, you're in more trouble than can be solved by blocking interactive Python (and if you're at least semi-serious about security, there are already hundreds of red flag events). Cheers, Steve