It appears that ssh, when launched in the ood_pun_t context can’t access things that ssh appears to be able to normally access when run from an interactive command line. The raw errors are included below. Is this expected behavior? If so, I’ll cook up a SEL permit for it.
This might be fixed in 2.0.19 which included numerous SELinux policy changes to better support SSH operations in the PUN context. From the audit entries it’s not entirely clear what was denied access as it relates to SSH. I think what would help is take that audit log and do this:
cat /var/log/audit/audit.log | audit2allow
And provide the output. It would be better on 2.0.19 once that is released.
What OS are you on? We have tested this on live systems with RHEL 7.9. Curious if you are on RHEL 8.x and seeing a behavior we’ve not yet encountered.
Also do you know what kind of OnDemand specific operations are taking place when these audit logs are generated? Is this using the Shell app? Anything unique about the operations taking place when the logs are produced like anything non-standard WRT OnDemand install? If this is for example Shell app using SSH, how is SSH authentication handled? We’ve validated using SSH keys on NFS home as well as SSH host based authentication with SELinux, though more recently was just SSH host based auth.
Trying to understand if there is maybe some site-specific issue or something others would potentially see. If this turns out to be site-specific, would just recommend generating a local policy to avoid those denials. I can offer help with that if you’re not familiar with the process.
Boring old CentOS 7.9, fully patched as of Oct 27; viz:
[ric@ood ~]$ cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)
As far as I know, this is a vanilla ondemand install, although it goes back to mid-1.x times and has been yum updated since then. User homes are NFS mounted on ood, and ssh keys are used for access. Sadly, these messages don’t include a UID, so I can’t pin this to any one account. I tried a time based search of ondemand-nginx logs and didn’t find anything of interest. If there’s any logs that would be helpful, let me know what to send along.
I forced our dev system running SELinux to use my SSH keys stored on NFSv4 and not able to reproduce the issue when opening Shell app. Granted we are running nightly builds on this host which include changes in 2.0.19 that hasn’t yet been released to 2.0 repo.
I do not think the SELinux policy changes we made in 2.0.19 will help the denials you are seeing. I am hesitant to add SELinux policy changes that are not well understood. I think for now your best bet is to install a custom policy with those denials allowed. Something like this:
If you want to inspect the policy before hand before running semodule you can inspect the ood-allow.te to make sure it’s what you want and then compile the policy with this:
make -f /usr/share/selinux/devel/Makefile
semodule -i ood-allow.pp