Bug 1746464

Summary: Default fapolicyd policy prevents Ansible from running
Product: Red Hat Enterprise Linux 8 Reporter: Jan Černý <jcerny>
Component: fapolicydAssignee: Radovan Sroka <rsroka>
Status: CLOSED ERRATA QA Contact: Dalibor Pospíšil <dapospis>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 8.0CC: dapospis, jerome.meyer, jjaburek, jpazdziora, kkinge, mhaicman, sgrubb, tjaros
Target Milestone: rcKeywords: Triaged
Target Release: 8.2Flags: pm-rhel: mirror+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: fapolicyd-0.9.1-2.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-28 15:58:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Output of fapolicyd --debug none

Description Jan Černý 2019-08-28 14:11:45 UTC
Description of problem:
Enabling fapolicyd service disables any execution of any Ansible playbook.
I think that is because the default fapolicyd policy  denies Ansible access.
The offending fapolicyd rule seems to be `deny_audit  all ftype=text/x-python` on line 38 in /etc/fapolicyd/fapolicyd.rules. This rule denies all processes access to mime type text/python files. Commenting out this rule and restarting the fapolicyd service enables Ansible playbooks again.

Version-Release number of selected component (if applicable):
fapolicyd-0.8.10-3.el8.x86_64

How reproducible:
always

Steps to Reproduce:
1. enable and start fapolicyd
2. run any Ansible playbook using `ansible-playbook` command


Actual results:
----8<----8<----8<----8<----8<----8<----
fatal: [localhost]: FAILED! => {"msg": "failed to transfer file to /root/.ansible/tmp/ansible-tmp-1566475092.171077-17672708694646/AnsiballZ_setup.py: [Errno 1] Operation not permitted: b'/root/.ansible/tmp/ansible-local-5312ufqw4bxf/tmpu7qy5tlt'"}
----8<----8<----8<----8<----8<----8<----

Expected results:
Ansible playbook runs without problems.

Additional info:
-

Comment 1 Steve Grubb 2019-08-30 21:40:36 UTC
The rule that is blocking this is working the way it's supposed to. The philosophy is that you carve out exceptions (whitelists) and then you block everything else. Notice that there is an exception for dnf higher up in the file.

So, to carve out the right exception, we need to know a few things. Assuming it happened today, what does the following command show?

ausearch --start today -m fanotify --raw | aureport --file -i

Comment 2 Jan Černý 2019-09-02 07:05:57 UTC
This command isn't helpful, because it shows:

----8<----8<----8<----8<----8<----8<----

ausearch --start today -m fanotify --raw | aureport --file -i

File Report
===============================================
# date time file syscall success exe auid event
===============================================
<no events of interest were found>

----8<----8<----8<----8<----8<----8<----

I reproduced the ansible-playbook fail multiple times before I run that command. Could it be that the events of this type are not audited? I'm on a default configuration. Do I need to add some other rule to fapolicyd policy or restart fapolicyd with some option to get any message?

Comment 3 Steve Grubb 2019-09-05 22:17:31 UTC
Something might be wrong with the rules. The rules should say deny_audit wherever it is denying access. Looking at the rules shipped, they all have deny_audit.

Comment 4 Steve Grubb 2019-10-20 15:49:07 UTC
I wonder if a rule like this placed above the python rules solves the problem?

allow uid=0 dir=/root/.ansible/tmp/

Comment 5 Marek Haicman 2019-10-24 07:47:27 UTC
Hello Jan,
unfortunately I was not able to reproduce the issue. Can you take a look and find out what ansible rule can trigger this bug? Does it happen in `--check` mode as well?

Comment 6 Jan Černý 2019-10-24 08:27:16 UTC
Hello Marek,

I am still able to reproduce this issue. Right now I use ansible-2.8.5-2.el8ae.noarch and fapolicyd-0.8.10-3.el8.x86_64. 

I try the example playbooks such as

----8<----8<----8<----8<----8<----8<----

---
- hosts: localhost
  tasks:
          - ping:

----8<----8<----8<----8<----8<----8<----

or


----8<----8<----8<----8<----8<----8<----

---
- hosts: localhost
  tasks:
          - lineinfile:
                  path: /tmp/testfile
                  line: Hello

----8<----8<----8<----8<----8<----8<----

I think there can be problem with multiple Ansible modules, if not with all of them.

Regarding your last question: yes, the error happens in both with --check and without --check.

However, with the current version of Ansible, I now get more complex error messages:


----8<----8<----8<----8<----8<----8<----

# ansible-playbook playbook.yml
 [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'


PLAY [localhost] **************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ********************************************************************************************************************************************************************************************
fatal: [localhost]: FAILED! => {"ansible_facts": {}, "changed": false, "failed_modules": {"setup": {"exception": "Traceback (most recent call last):\n  File \"/root/.ansible/tmp/ansible-tmp-1571905208.8638227-167612996263276/AnsiballZ_setup.py\", line 114, in <module>\n    _ansiballz_main()\n  File \"/root/.ansible/tmp/ansible-tmp-1571905208.8638227-167612996263276/AnsiballZ_setup.py\", line 106, in _ansiballz_main\n    invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\n  File \"/root/.ansible/tmp/ansible-tmp-1571905208.8638227-167612996263276/AnsiballZ_setup.py\", line 48, in invoke_module\n    with open(module, 'rb') as mod:\nPermissionError: [Errno 1] Operation not permitted: '/tmp/ansible_setup_payload_yvnjw8_j/__main__.py'\n", "failed": true, "module_stderr": "Traceback (most recent call last):\n  File \"/root/.ansible/tmp/ansible-tmp-1571905208.8638227-167612996263276/AnsiballZ_setup.py\", line 114, in <module>\n    _ansiballz_main()\n  File \"/root/.ansible/tmp/ansible-tmp-1571905208.8638227-167612996263276/AnsiballZ_setup.py\", line 106, in _ansiballz_main\n    invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\n  File \"/root/.ansible/tmp/ansible-tmp-1571905208.8638227-167612996263276/AnsiballZ_setup.py\", line 48, in invoke_module\n    with open(module, 'rb') as mod:\nPermissionError: [Errno 1] Operation not permitted: '/tmp/ansible_setup_payload_yvnjw8_j/__main__.py'\n", "module_stdout": "", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1}}, "msg": "The following modules failed to execute: setup\n"}

PLAY RECAP ********************************************************************************************************************************************************************************************************
localhost                  : ok=0    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0   


----8<----8<----8<----8<----8<----8<----


Removing `deny_audit  all ftype=text/x-python` on line 38 in /etc/fapolicyd/fapolicyd.rules and then running `systemctl restart fapolicyd` still workarounds the problem for me.

Comment 8 Jan Černý 2019-10-24 12:26:41 UTC
Created attachment 1628853 [details]
Output of fapolicyd --debug

Comment 9 Steve Grubb 2019-10-24 12:50:58 UTC
Based on that output, perhaps this would fix it:

allow uid=0 dir=/tmp/ansible
allow uid=0 dir=/root/.ansible/tmp/

This needs to be just above the python rules so that it picks these first.

Comment 10 Jiri Jaburek 2019-11-06 17:06:26 UTC
Jan, can you try ^^^^ and report back? .. Thanks.

Comment 11 Jan Černý 2019-11-07 08:17:46 UTC
Hi Jiri,
Yes, I have added the 2 lines from Comment 9 right before line "allow all dir=execdirs ftype=text/x-python" in /etc/fapolicyd/fapolicyd.rules and restarted fapolicyd service and then the Ansible error has disappeared.

Comment 12 Steve Grubb 2019-11-08 08:44:23 UTC
Thanks for the update. We'll adjust the default policy to include these rules.

Comment 24 errata-xmlrpc 2020-04-28 15:58:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:1687