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