[issue43438] [doc] sys.addaudithook() documentation should be more explicit on its limitations

Steve Dower added the comment: If someone offers a patch for replacing the list of per-interpreter hooks with something not easily discoverable via gc, I'm sure we'd take it. It's all internal, so just hiding it from the list of bases should be fine (there should never be more than one refer

[issue43438] [doc] sys.addaudithook() documentation should be more explicit on its limitations

Saiyang Gou added the comment: > Please also keep in mind that sys.addaudithook() does **not** add a global > hook. The function adds a per-interpreter hook. Yes, I'm aware of this. And this should be better documented. When I was playing around with audit hooks and reading the source code,

[issue43438] [doc] sys.addaudithook() documentation should be more explicit on its limitations

Christian Heimes added the comment: Python's dynamic nature makes it hard to implement and reason about audit hooks written in Python. sys.addaudithook() is really only design for testing, debugging, and playing around with auditing. You absolutely have to write a custom interpreter if you w

[issue43438] [doc] sys.addaudithook() documentation should be more explicit on its limitations

Saiyang Gou added the comment: We understand that audit hooks should not be used to build a sandbox with Python. It is natural for audit hooks to appear in CTF challenges though, as many CTF challenges intentionally try to use a wrong way to secure a system (and let players prove it wrong).

[issue43438] [doc] sys.addaudithook() documentation should be more explicit on its limitations

Frank added the comment: PEP 551 is confusing. It looked suggesting that it's a "security tool" that "detects, identifies and analyzes misuse of Python" to me (and apparently many others). examples shown in the PEP includes WannaCrypt, APTs, all of which involves the good old remote code ex

[issue43438] [doc] sys.addaudithook() documentation should be more explicit on its limitations

Change by JIanqiu Tao : -- nosy: +zkonge ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

[issue43438] [doc] sys.addaudithook() documentation should be more explicit on its limitations

STINNER Victor added the comment: Another example of recent Capture The Flag challenge which used audit hooks: https://bugs.python.org/issue42800#msg384143 -- ___ Python tracker

[issue43438] [doc] sys.addaudithook() documentation should be more explicit on its limitations

Christian Heimes added the comment: I agree with both of you. The documention should explicitly state that the audit hooks are for auditing. They are not designed to sandbox Python. When used correctly, they can help to capture and analyze an event post-mortem. The documentation of sys.adda

[issue43438] [doc] sys.addaudithook() documentation should be more explicit on its limitations

Steve Dower added the comment: To clarify my position on this (as the PEP author): * audit hooks added *after* initialization (including via the Python API) are not intended for security, but for logging/debugging, and so bypasses are not considered security issues * audit hooks added *befor

[issue43438] [doc] sys.addaudithook() documentation should be more explicit on its limitations

STINNER Victor added the comment: See also bpo-43439: [security] Add audit events on GC functions giving access to all Python objects. -- ___ Python tracker ___ _

[issue43438] [doc] sys.addaudithook() documentation should be more explicit on its limitations

New submission from STINNER Victor : Recently, the PEP 578 audit hooks was used to build a Capture The Flag (CTF) security challenge, AntCTF x D^3CTF: https://d3ctf.io/ Multiple issues have been reported to the Python Security Response Team (PSRT) from this challenge. It seems like there was