PEP 768: Flesh out the security design #4169
Conversation
Switch from a buffer containing Python code to a buffer containing the path to a file containing Python code. This helps to prevent an attacker with arbitrary memory write capabilities inside a running Python process from also gaining arbitrary code execution if they don't already have the ability to write to the file system. Also, indicate that we will send a new audit event whenever this interface is used, so that any attacker who uses it risks detection. Signed-off-by: Matt Wozniski <[email protected]>
Signed-off-by: Matt Wozniski <[email protected]>
|
@godlygeek we need to update the "Using a path as the debugger input" to contain the reverse: using a script as the debugger input :) |
Signed-off-by: Matt Wozniski <[email protected]>
|
Good call, fixed. |
Signed-off-by: Matt Wozniski <[email protected]>
|
CC @zooba After investigating a bit we have switched the design from a buffer holding the code to a buffer holding the path to elevate the security profile of in process threats so an attacker with write memory access doesn't automatically gain execution access. |
|
Of course I see this comment after I review the other PR and complain about mentioning files 😆 This is a fine change. Make sure in the implementation that |
We will figure it out 👍 |
Switch from a buffer containing Python code to a buffer containing the path to a file containing Python code. This helps to prevent an attacker with arbitrary memory write capabilities inside a running Python process from also gaining arbitrary code execution if they don't already have the ability to write to the file system.
Also, indicate that we will send a new audit event whenever this interface is used, so that any attacker who uses it risks detection.
📚 Documentation preview 📚: https://pep-previews--4169.org.readthedocs.build/