SELinux + ood +ssh errors

Get Help
,
1

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.

Thanks,
Ric

type=AVC msg=audit(11/01/21 21:51:23.861:255871) : avc:  denied  { open } for  pid=27218 comm=ssh path=/etc/selinux/targeted/contexts/files/file_contexts.subs_dist dev="dm-0" ino=101214886 scontext=system_u:system_r:ood_pun_t:s0 tcontext=system_u:object_r:file_context_t:s0 tclass=file permissive=1
type=AVC msg=audit(11/01/21 21:51:23.861:255871) : avc:  denied  { read } for  pid=27218 comm=ssh name=file_contexts.subs_dist dev="dm-0" ino=101214886 scontext=system_u:system_r:ood_pun_t:s0 tcontext=system_u:object_r:file_context_t:s0 tclass=file permissive=1
type=AVC msg=audit(11/01/21 21:51:23.861:255871) : avc:  denied  { search } for  pid=27218 comm=ssh name=files dev="dm-0" ino=101219562 scontext=system_u:system_r:ood_pun_t:s0 tcontext=system_u:object_r:file_context_t:s0 tclass=dir permissive=1
2

We may have patched this in 2.0.19, @tdockendorf?

3

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.

4

here you go
`[ric@ood ~]$ sudo cat /var/log/audit/audit.log.1 | audit2allow

#============= ood_pun_t ==============
allow ood_pun_t file_context_t:dir search;
allow ood_pun_t file_context_t:file { open read };
allow ood_pun_t security_t:file write;
allow ood_pun_t security_t:security check_context;
allow ood_pun_t self:process setfscreate;`

5

If you do these 3 separate commands, what do you get?

grep file_context_t /var/log/audit/audit.log | grep ood_pun_t
grep security_t /var/log/audit/audit.log | grep ood_pun_t
grep setfscreate /var/log/audit/audit.log | grep ood_pun_t

I am curious what exactly is attempting to be accessed , especially with the write and the setfscreate.

If you don’t wish to share the logs publicly, feel free to email to me directly at tdockendorf AT osc DOT edu.

6 
[root@ood ~]# grep file_context_t /var/log/audit/audit.log.1 | grep ood_pun_t
type=AVC msg=audit(1635828683.861:255871): avc:  denied  { search } for  pid=27218 comm="ssh" name="files" dev="dm-0" ino=101219562 scontext=system_u:system_r:ood_pun_t:s0 tcontext=system_u:object_r:file_context_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1635828683.861:255871): avc:  denied  { read } for  pid=27218 comm="ssh" name="file_contexts.subs_dist" dev="dm-0" ino=101214886 scontext=system_u:system_r:ood_pun_t:s0 tcontext=system_u:object_r:file_context_t:s0 tclass=file permissive=1
type=AVC msg=audit(1635828683.861:255871): avc:  denied  { open } for  pid=27218 comm="ssh" path="/etc/selinux/targeted/contexts/files/file_contexts.subs_dist" dev="dm-0" ino=101214886 scontext=system_u:system_r:ood_pun_t:s0 tcontext=system_u:object_r:file_context_t:s0 tclass=file permissive=1
type=AVC msg=audit(1635828683.861:255872): avc:  denied  { read } for  pid=27218 comm="ssh" name="file_contexts" dev="dm-0" ino=101892098 scontext=system_u:system_r:ood_pun_t:s0 tcontext=unconfined_u:object_r:file_context_t:s0 tclass=file permissive=1
type=AVC msg=audit(1635828683.861:255872): avc:  denied  { open } for  pid=27218 comm="ssh" path="/etc/selinux/targeted/contexts/files/file_contexts" dev="dm-0" ino=101892098 scontext=system_u:system_r:ood_pun_t:s0 tcontext=unconfined_u:object_r:file_context_t:s0 tclass=file permissive=1
[root@ood ~]#
[root@ood ~]# grep security_t /var/log/audit/audit.log.1 | grep ood_pun_t
type=AVC msg=audit(1635828683.863:255873): avc:  denied  { write } for  pid=27218 comm="ssh" name="context" dev="selinuxfs" ino=5 scontext=system_u:system_r:ood_pun_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=file permissive=1
type=AVC msg=audit(1635828683.863:255874): avc:  denied  { check_context } for  pid=27218 comm="ssh" scontext=system_u:system_r:ood_pun_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security permissive=1
[root@ood ~]#
[root@ood ~]# grep setfscreate /var/log/audit/audit.log.1 | grep ood_pun_t
type=AVC msg=audit(1635828683.863:255875): avc:  denied  { setfscreate } for  pid=27218 comm="ssh" scontext=system_u:system_r:ood_pun_t:s0 tcontext=system_u:system_r:ood_pun_t:s0 tclass=process permissive=1
7

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.

8

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.

Thanks,

Ric

image001.png

image002.png

9

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:

cat /var/log/audit/audit.log | audit2allow -M ood-allow
semodule -i ood-allow.pp

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
10

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.