[Security-sig] PEP 551: Security transparency in the Python runtime

[Steve Dower]

On 24Aug2017 1241, James Powell wrote:
>
>>> Like, we're inevitably going to
>>> have people trying to use 'spython' to replace their normal python
>>> 'because it's more secure' and stuff like that. Would it make sense to
>>> call it something else, like 'tpython' (for 'transparent'), or
>>> 'stdemo-python' (to emphasize that it's more intended as an example and
>>> starting point rather than a useful product)?
>
> This is an important point. It's going to be critical that we appropriately convey what "security transparency" means. I believe we can do this.
>
> Many of the convenience features (e.g., Windows-specific integrations like ETW) attached to this project should be made generally available. We should encourage users to deploy spython only where security transparency truly makes sense, and discourage its deployment where users just want access to some integration feature.
>
> (Note that it may not even make sense to deploy spython for work that requires ctypes or cffi or numpy or pywin32 or any other library that could allow raw memory access.)

Agreed. This is the point of the Recommendations section, and 
specifically the recommendation to not distribute any spython build 
outside of your own network (I explicitly said that python.org won't 
distribute builds, and it's up to any other distributors to make their 
own call).

If you build from source, you'll get spython, but currently I don't 
think it'll install from source (I certainly didn't change anything to 
make that work). That's the way I expect it to stay.

I think platform specific functionality should be kept separate, if only 
because testing and maintaining it is so much more difficult. Ideally 
security vendors will offer their own versions that organizations can 
build upon which integrate with their tools (and Microsoft certainly 
falls into this category for OS functionality like DeviceGuard and ETW), 
but I don't want our volunteers to have to worry about configuring test 
machines on their free time just to make sure it doesn't break (or to 
get caught up in liability disputes if someone relies on it when they 
really should have done due diligence).

Also, integration into things like the logging module (for ETW on 
Windows) are totally unrelated to this PEP. All it takes is someone to 
write the extension module and ship it on PyPI.


As an aside, one of Microsoft's top security guys saw a tweet about this 
and posted some screenshots of Python payloads in actual malware:

https://twitter.com/JohnLaTwC/statuses/900807173495771140

My favourite part is the Python 2.x and 3.x compatibility in the MacOS 
path of the first one :) (the Windows path in that one uses PowerShell).

Cheers,
Steve