SELinux prevents playbooks from ssh-ing

Get Help
, , ,
1

Hello!

My problem is on a disconnected system so I can’t cut & paste.
It’s also my first posting, so I don’t have the formatting that everyone likes, my apologies.

I am having an issue where a playbook will not run on another system with SELinux enabled on the local system. Both systems are RHEL 8.10.
A standard ssh (without ansible involved) from the local system to the remote system works just fine with the same user.
Setting selinux to Permissive allows the playbook to complete.
The playbook does not need elevated privileges to run.

The connection does occur, at least it tries to. A tail of /var/log/secure on the remote system shows the login.
It does give some SELinux context issues. However, the same messages show up with performing a standard ssh, which goes through just fine.

The home directory of the user (where the playbook is run from) is nfs mounted via autofs on both systems. Autofs seems to work just fine.

The ssh is performed with ssh keys, and also works fine. /var/log/secure shows it accepts the public key.
The related selinux errors are as follows:
pam_selinux[systemd-user:session]: Unable to get valid context for username
pam_selinux[systemd-user:session]: conversation failed
PAM failed: Cannot make/remove an entry for the specified session
user@220237.service: Failed to set up PAM session: Operation not permitted

The above lines show up whether I’m doing ssh, or ansible-playbook. One works, the other doesn’t.
python3-libselinux.x86_64.rpm is installed, in case that matters.

It’s hard for me to tell which system is closing the connection. Since ssh works fine, it appears there’s something Ansible just doesn’t like, but I’m at a loss.

Thanks for any troubleshooting assistance!

2

Is ansible targeting the system python, or another instance? Having this installed does matter, but it also needs to be in the same python environment that invokes when it is executing.

Have you tried running ansible with -vvvv (that’s 4 v’s, for connection debugging) to see if you get more connection related information like you would with ssh -vvv

I also often find this guide helpful with hunting down SELinux issues. Specifically the bits about using something like this

journalctl -t setroubleshoot --since=[time]

to find specific issues.

I hope that smattering of ideas helps.

1 Like
3

Your ssh login does not require any filesystem actions, Ansible on the other hand, copies files over to execute them, this is how modules work. Try using raw to run a command, if that 'just works’TM, that would confirm my guess. You can also set pipelining to ‘on’, but you will still have issues with copying files via copy or other file based actions. Another thing you can try, is setting remote_tmp to avoid the selinux issues.

1 Like
4

Not fully understanding raw, but I did look it up and tried it with a very simple playbook

---
# packagelisting.yml
- name: Get Package Listing
  hosts: host2
  become: no
  gather_facts: false

  tasks:
  - name: List the Packages
    raw: "rpm -qa > /home/mmarrone/packagelisting.txt"

[mmarrone@host1]$ ansible-playbook -i ../hosts package_listing.yml

I still get the unreachable error (although it does still log on). Running this with SELinux in permissive works just fine.

Thanks!

5

That was good information.
Following the guide you posted, I learned:

SELinux is preventing /usr/bin/ssh from create access on the sock file /home/mmarrone/.ansible/cp/blahblahblah

It gave the “solution” of:

# ausearch -c 'ssh' --raw | audit2allow -M my-ssh
# semodule -X 300 -i my-ssh-pp

Which indeed did the trick (so I consider this partially solved, and thank you! I have other related SELinux issues which I’ll use this as a guide to fixing, so double thanks!)

But it seems this is a specific fix, and one I’d have to run on every newly kicked box. Obviously this is now a SELinux issue (as opposed to Ansible), but is there a better way to fix this? Labels, contexts, etc?
(I’m not well versed in SELinux, as you can probably tell)

Thanks!

6

To fix the issue and keep selinux, the advice above of looking at the logs will give you the info about what needs to be tagged in what context, it can get laborious, but normally worth it for the added security.

1 Like
7

As you develop each playbook, you’ll likely need to create custom SELinux policies, but those policies are portable given the correct conditions.

So you could develop them on a test server, and deploy them more broadly.

I suspect that after you lay the foundation of being able to login with ansible, you should be able to use that for deployment of other policies as well.

1 Like
8

Thanks for your advice everyone!