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

[Steve Dower]

On 24Aug2017 1116, Nathaniel Smith wrote:
> I don't have any particular security expertise, but a few thoughts anyway...

Glad to hear them!

> - your big list of logged events seems to be missing
> getaddrinfo/getnameinfo (the modern replacements for get*by*)

Indeed, added! They'll be in the next update.

> - you make it possible for arbitrary code to log arbitrary events by
> calling sys.loghook, which seems useful if you want to allow e.g. cffi
> to log similar events to the ones that ctypes logs. But are you worried
> that attackers could use the ability to forge arbitrary events to cover
> their trail?

I raised this question with some of our defenders and they don't think 
it's a serious concern, especially since an attacker could "forge" real 
events by taking the action and ignoring the result.

For example, a lot of malware will use DNS resolution as a kill-switch. 
When a name stops resolving (or when it starts resolving), it wipes 
itself. The attacker could attempt to DoS the log analysis by resolving 
hundreds of randomly generated names, thereby letting defenders know 
that *something* is going on, but making it really hard to figure out 
exactly what is going on.

It's thought unlikely that malicious code would reduce the number of 
events compared to normal operation, so any increase - real or forged - 
is an indication of a problem. About the only valid use case I can come 
up with for forging events is when an attacker suppresses all events but 
wants things to continue to look normal, and it's much easier to do this by:

* infect normal running process and suppress all events
* spawn undetected subprocess and suppress all its events
* crash the original process and let the host restart it automatically 
(very likely on a running server)
* do all your work in the subprocess that nobody expects to see messages 
from anyway

Basically, when weighed against the ability for libraries like cffi and 
pywin32 to add their own contributions to the log, it is worth the risk 
to allow extra messages.

(And let me know if you think this explanation is important to have in 
the PEP text somewhere.)

> - the name "spython" makes me nervous, because I feel like as soon as
> discussion switches from specifics like "transparency through event
> logging" to vague abstractions like "secure", then it becomes much more
> difficult to have useful discussions. 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)?

Who said "secure"? :) Given the lack of command-line arguments and 
interactive mode, "stupid" is the more likely interpretation of the 's' 
(though I also liked the suggestion that it's for "spy-thon", since we 
can spy on what it's doing).

The most likely true meaning is "system" - many of the people involved 
in the Linux distros have been talking about having a separate system 
Python for their tools that is not exposed to users, and part of the 
intent of this entry point is to fulfill that need. Whether it will or 
not is an open question, but I'm keen to adapt this part of the PEP to 
be most useful to distributors, since the point of it is to be the 
starting point of the exact entry point they need. (And also to be able 
to test some of the features in the test suite.)

Cheers,
Steve