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
_______________________________________________
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig
