Fixing PUN management of config home

[djareval]

Suggested fix for #5132, incorporating interfaces from policy/modules/contrib/gnome.if

I've tested this successfully on our RHEL 9 instance of OOD.

Regarding #4651 (comment): config_home_t is not specific to local $HOME. NFS-mounted home will use all standard labels assuming fcontext rules are set (examples in the semanage-fcontext man page show a simple way to do this). Possibly the webdev02 example shown is using the context= mount option to set nfs_t? Mount option would override the label in ondemand-selinux.fc, so containing it in a boolean should not be necessary.

[johrstrom]

Sorry I may have just created a merge conflict with this in #5166.

@treydock please advise.

[treydock]

The default context for NFS is nfs_t. It can be changed at mount to some other context, but generally the entire mount's contents are a single context.

This is our mount in autofs:

*       -rw,vers=4.0,rsize=65536,wsize=65536    &.ten.osc.edu:/&

My home:

$ grep sysp /proc/mounts
<NFS SERVER>:/sysp /users/sysp nfs4 rw,relatime,vers=4.0,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=<OMIT>,local_lock=none,addr=<OMIT> 0 0

$ sudo ls -laZ /users/sysp/ | grep tdockendorf
drwxr-xr-x. 166 tdockendorf PZS0708 system_u:object_r:nfs_t:s0     65536 Mar 18 09:21 tdockendorf

[treydock]

Getting rid of the tunable is the wrong approach. The context trying to be forced here does not apply to everyone so should not be forced on everyone.

[djareval]

Thanks @treydock.
I would argue that the context does apply to every setup that is capable of utilizing SELinux context labels. In your case, NFSv4.0 doesn't support the security xattrs required for SELinux contexts, so it's not actually using them, just bypassing with a blanket nfs_t.

But I wouldn't think that's an issue; there are other default SELinux context labels that your NFSv4.0 isn't utilizing (user_home_dir_t and user_home_t) but that doesn't cause any problems, does it?

[treydock]

I'm not 100% certain how this will work on NFS v4.0 and easiest way to test will be to verify at OSC with our nightly builds once merged. We run SELinux only on our dev nightly hosts and only in permissive mode.

[treydock]

Doing this would require something to either run restorecon if already exists or the new directory would inherit this context.

However this doesn't work on NFS.

$ sudo chcon -R -t config_home_t /users/sysp/tdockendorf/.config/ondemand
chcon: failed to change context of 'settings.yml' to ‘system_u:object_r:config_home_t:s0’: Operation not supported
chcon: failed to change context of '/users/sysp/tdockendorf/.config/ondemand' to ‘system_u:object_r:config_home_t:s0’: Operation not supported

This change will cause issues for people using NFS home directories which is one of the more common usages with OnDemand.

[djareval]

Agreed, this would require running restorecon.

That chcon failure may be due to using NFSv4.0, which doesn't support the security xattrs required for SELinux contexts. We use NFSv4.2 for home and have no issue running chcon:

$ restorecon -FRv ~/.config/ondemand
$ chcon -R -t user_tmp_t ~/.config/ondemand
$ restorecon -FRv ~/.config/ondemand
Relabeled /mnt/home/djareval/.config/ondemand from staff_u:object_r:user_tmp_t:s0 to staff_u:object_r:config_home_t:s0
Relabeled /mnt/home/djareval/.config/ondemand/settings.yml from staff_u:object_r:user_tmp_t:s0 to staff_u:object_r:config_home_t:s0

But this proposed change shouldn't negatively impact a setup like yours. For instance, the SELinux policy on your system probably lists default contexts other than nfs_t for your home files. Here's our on RHEL 9.7:

$ matchpathcon ~
/home/djareval   staff_u:object_r:user_home_dir_t:s0

$ matchpathcon ~/.config/ondemand
/home/djareval/.config/ondemand  staff_u:object_r:config_home_t:s0

But running restorecon on the home directories just has no effect? Or does it also generate errors?

[treydock]

Why is this using gnome_config_filetrans and not filetrans_pattern?

[djareval]

Practicing encapsulation. Using filetrans_pattern would require referencing config_home_t directly, thus adding another line to the require block. Ideally the only type labels in the file would be ood*_t. Any interaction with extenral types should happen through interface calls and gnome_config_filetrans seems to fit the bill exactly for the needed transition.