From a46836daba664a5187c5fa4a063c055b7e5a466f Mon Sep 17 00:00:00 2001 From: Alex Willmer Date: Mon, 25 Mar 2024 22:44:14 +0000 Subject: [PATCH] Updated AnsibleUnsafe notes (rest) --- AnsibleUnsafe-notes.rest | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/AnsibleUnsafe-notes.rest b/AnsibleUnsafe-notes.rest index af6c13b..b5a3d55 100644 --- a/AnsibleUnsafe-notes.rest +++ b/AnsibleUnsafe-notes.rest @@ -31,8 +31,8 @@ Origin Where unsafe is applied =================== ========================================================= -Implementation internals ------------------------- +Implementation details +---------------------- ``AnsibleUnsafe`` objects are marked by the attribute ``__UNSAFE__=True``. In Ansible <= 6 (ansible-core <= 2.13) casting to the base type removes it @@ -191,18 +191,24 @@ Run ansible and view the file contents File ".../ansible/utils/unsafe_proxy.py", line 208, in _strip_unsafe traceback.print_stack(file=f) -Discussion ----------- - Observations +------------ - ``ansible.utils.unsafe_proxy.*`` is only available on the Ansible controller. The module isn't part of ``ansible.module_utils``, so not available on targets. - Pickling/unpickling does not strip the unsafe marker. +- JSON encoding/decoding strips the unsafe marker. This happens to + ``AnsibleModule`` arguments serialised in + ``ansible.executor.module_common._find_module_utils()``. + +Discussion +---------- Informed guesses of rules/design principals -- The Ansible controller is the most valued security boundary, then targets. +- The Ansible controller is the most valued security perimeter. +- Targets are required/assumed to trust all input from the controller. + By design they execute any arbitrary code that it sends. - All templating should/does happen on the controller (80% sure). - Ansible targets cannot/should not try to mark a value as safe or unsafe. The controller couldn't trust that determination anyway.