PEP 768: Expand the security considerations section

Signed-off-by: Pablo Galindo <pablogsal@gmail.com>

Author: pablogsal

peps/pep-0768.rst

@@ -294,6 +294,24 @@ An example usage of the API would look like:
     except Exception as e:
         print(f"Failed to execute code: {e}")
 
+Configuration API
+-----------------
+
+To allow redistributors, system administrators, or users to disable this
+mechanism, several methods will be provided to control the behavior of the
+interpreter:
+
+A new environment ``PYTHON_DISABLE_REMOTE_DEBUGGING`` environment variable will
+be provided to control the behaviour at runtime. If set to any value, the
+interpreter will ignore any attempts to attach a debugger using this mechanism.
+
+This environment variable will be added together with a new ``-X disable-remote-debugging``
+flag to the Python interpreter to allow users to disable this feature at runtime.
+
+Additionally a new  ``--without-remote-debugging`` flag will be added to the
+``configure`` script to allow redistributors to build Python without support for
+remote debugging if they so desire.
+
 
 Backwards Compatibility
 =======================
@@ -310,6 +328,10 @@ processes that can already write to arbitrary memory within your process and
 execute arbitrary code on the machine (in order to create the file containing
 the Python code to be executed).
 
+Furtermore, the execution of the code is done is gated by the interpreter's
+audit hooks, which can be used to monitor and control the execution of the code
+in sensitive environments.
+
 Existing operating system security mechanisms are effective for guarding
 against attackers gaining arbitrary memory write access. Although the PEP
 doesn't specify how memory should be written to the target process, in practice
@@ -368,6 +390,33 @@ proposed interface.
 By maintaining compatibility with existing security frameworks, this design
 ensures that adopting the new interface requires no changes to established.
 
+Security scenarios
+------------------
+
+* For an external attacker, the ability to write to arbitrary memory in a
+  process is already a severe security issue. This interface does not introduce
+  any new attack surface, as the attacker would already have the ability to
+  execute arbitrary code in the process. This interface behaves in exactly
+  the same way as existing debuggers, and does not introduce any new additional
+  security risks.
+* For an attacker who has gained arbitrary memory write access to a process but
+  not arbitrary code execution, this interface does not provide a way to escalate
+  to arbitrary code execution as long as the attacker has not gained control over
+  additional machine resources external to the program. 
+  
+Additionally, the fact that the code to be executed is gated by the interpreter's
+audit hooks means that the execution of the code can be monitored and controlled
+by system administrators. This means that even if the attacker has compromised the
+application **and the filesystem**, leveraging this interface for malicious
+purposes provides a very risky proposition for an attacker, as they risk
+exposing their actions to system administrators that could not only detect the
+attack but also take action to prevent it. Finally, is important to note that
+if an attacker has arbitrary memory write access to a process and has compromised
+the filesystem, they can already escalate to arbitrary code execution using
+other existing mechanisms, so this interface does not introduce any new risks
+in this scenario.
+
+
 How to Teach This
 =================