Add vncsession-restore script to restore SELinux context

[grulja]

The vncsession-restore script is used in the ExecStartPre option for systemd service file in order to properly start the session in case the policy is updated (e.g. after Tigervnc update).

Note: the original solution where we call restorecon in vncsession might be either removed or can be kept in case someone runs this outside systemd, but it doesn't seem to be enough when Tigervnc is started as systemd service.

Keeping this as WIP for now as I'm trying to test it properly, but any feedback is welcomed.

cc: @zpytela @vmojzis

[grulja]

Testing workflow (with SELinux set to Enforcing):

1. Install Tigervnc 1.11.0.
2. Remove and re-create ~/.vnc with vncpasswd and make sure that ls -Zd ~/.vnc has old xdm_home_t context.
3. Update Tigervnc to 1.12.0 + this change.
4. Configure /etc/tigervnc/vncserver.users and /etc/tigervnc-vncserver-config-defaults accordingly.
5. Start with sudo systemctl start vncserver@:x
6. Check that ls -Zd ~/.vnc has correct vnc_home_t context and sudo systemctl status vncserver@:x shows a running session.

[CendioOssman]

Are you saying that #1372 did not fix the issue fully?

[grulja]

Are you saying that #1372 did not fix the issue fully?

Unfortunately it did not. This seems to fix it and I asked here: https://bugzilla.redhat.com/show_bug.cgi?id=2042535 if someone else can confirm it fixes the issue for him as well.

[CendioOssman]

I'm still confused. The linked bugzilla thread suggests that #1372 was a sufficient fix. What exactly is still breaking?

[grulja]

I'm still confused. The linked bugzilla thread suggests that #1372 was a sufficient fix. What exactly is still breaking?

E.g. this comment https://bugzilla.redhat.com/show_bug.cgi?id=2042535#c9 suggest it's still not working and I can reproduce that. When I downgrade to Tigervnc 1.11.0 and setup a user, then upgrading to Tigervnc 1.12.0 (having SELinux in Enforcing mode) and starting the vncserver service, it fails to start. When SELinux is in Permissive mode, it will work and you will see the SELinux context has changed.

[CendioOssman]

All right. I'd like to see a more exact analysis of why the existing method is failing though. Perhaps it can be fixed?

[grulja]

I can see following AVC:

time->Wed Feb  2 14:36:58 2022
type=AVC msg=audit(1643809018.444:3129): avc:  denied  { search } for  pid=74833 comm="vncsession" name=".vnc" dev="dm-0" ino=34476192 scontext=system_u:system_r:vnc_session_t:s0 tcontext=unconfined_u:object_r:xdm_home_t:s0 tclass=dir permissive=0

[grulja]

There are three calls on the .vnc directory, first is mkdir() trying to create it and remaining two are selinux_file_context_verify() and selinux_restorecon(). I tried to move the SELinux so it's called before mkdir(), but it had same result. I was discussing this with @zpytela and @vmojzis and we tried to add several rules, but that didn't work and I was suggested to use this approach.

[CendioOssman]

Is it the check itself that might cause the issue? Should we perhaps do the relabeling unconditionally?

[grulja]

Is it the check itself that might cause the issue? Should we perhaps do the relabeling unconditionally?

Doesn't seem so. When I do that I still get:

----
time->Mon Feb  7 11:15:05 2022
type=AVC msg=audit(1644228905.346:1033): avc:  denied  { getattr } for  pid=262732 comm="vncsession" path="/home/testvnc/.vnc" dev="dm-0" ino=30814093 scontext=system_u:system_r:vnc_session_t:s0 tcontext=unconfined_u:object_r:xdm_home_t:s0 tclass=dir permissive=0
----
time->Mon Feb  7 11:15:05 2022
type=AVC msg=audit(1644228905.346:1034): avc:  denied  { search } for  pid=262732 comm="vncsession" name=".vnc" dev="dm-0" ino=30814093 scontext=system_u:system_r:vnc_session_t:s0 tcontext=unconfined_u:object_r:xdm_home_t:s0 tclass=dir permissive=0

And I see:
úno 07 11:15:05 fedora vncsession[262732]: Failure restoring SELinux context for "/home/testvnc/.vnc": Permission denied

In the journal log.

[grulja]

It works when I just run /usr/libexec/vncsession-start :15 (SELinux set to Enforcing) so it apparently works just fine, just not when it runs as systemd service.

Removing the SELinuxContext=system_u:system_r:vnc_session_t:s0 option from the service file doesn't make a difference.

[grulja]

Further investigating this, when I add following line into vncsession.fc, then even this solution doesn't work:
/usr/libexec/vncsession-restore -- gen_context(system_u:object_r:vnc_session_exec_t,s0)
I'm a complete SELinux noob, but perhaps it's

/usr/sbin/vncsession			--	gen_context(system_u:object_r:vnc_session_exec_t,s0)
/usr/libexec/vncsession-start		--	gen_context(system_u:object_r:vnc_session_exec_t,s0)

that makes it run with given context and fails afterwards? Even though when I disable it and also when I remove the SELinuxContext=system_u:system_r:vnc_session_t:s0 option from the service file it still doesn't run. It restores the context properly, but fails to start with:

----
time->Tue Feb  8 13:22:27 2022
type=AVC msg=audit(1644322947.065:1425): avc:  denied  { entrypoint } for  pid=150518 comm="(on-start)" path="/usr/libexec/vncsession-start" dev="nvme0n1p8" ino=4064530 scontext=system_u:system_r:vnc_session_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file permissive=0
----
time->Tue Feb  8 13:23:12 2022
type=AVC msg=audit(1644322992.761:1522): avc:  denied  { transition } for  pid=150734 comm="vncsession" path="/usr/libexec/vncserver" dev="nvme0n1p8" ino=4064489 scontext=system_u:system_r:unconfined_service_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process permissive=0

This change as it is works for me just fine.

[CendioOssman]

I'm afraid I don't have time to dig in to this right now. Perhaps one of the SELinux experts could have a look?