SELinux is preventing vncsession from create access on the directory .vnc. ***** Plugin catchall_boolean (89.3 confidence) suggests ****************** If you want to allow polyinstantiation to enabled Then you must tell SELinux about this by enabling the 'polyinstantiation_enabled' boolean. Do setsebool -P polyinstantiation_enabled 1 ***** Plugin catchall (11.6 confidence) suggests ************************** If you believe that vncsession should be allowed create access on the .vnc directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'vncsession' --raw | audit2allow -M my-vncsession # semodule -X 300 -i my-vncsession.pp Additional Information: Source Context system_u:system_r:vnc_session_t:s0 Target Context system_u:object_r:vnc_home_t:s0 Target Objects .vnc [ dir ] Source vncsession Source Path vncsession Port <Unknown> Host fedora Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-37.14-1.fc37.noarch Local Policy RPM tigervnc-selinux-1.12.0-7.fc37.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name fedora Platform Linux fedora 6.0.8-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 11 15:09:04 UTC 2022 x86_64 x86_64 Alert Count 2 First Seen 2022-11-17 14:36:24 CET Last Seen 2022-11-17 16:17:02 CET Local ID 2f75d126-6cb8-40e6-9af1-822f58831e46 Raw Audit Messages type=AVC msg=audit(1668698222.766:585): avc: denied { create } for pid=5966 comm="vncsession" name=".vnc" scontext=system_u:system_r:vnc_session_t:s0 tcontext=system_u:object_r:vnc_home_t:s0 tclass=dir permissive=0 Hash: vncsession,vnc_session_t,vnc_home_t,dir,create
Can you please share how do you start Tigervnc and what is your configuration in /etc/tigervnc?
I don't use it now. It was probably started by systemctl. /etc/tigervnc/vncserver.users :1=username
It seems this is command: systemctl start vncserver@:1
Caught in enforcing mode: ---- type=PROCTITLE msg=audit(01/12/2023 02:58:12.648:696) : proctitle=/usr/sbin/vncsession fedora :1 type=PATH msg=audit(01/12/2023 02:58:12.648:696) : item=1 name=/home/fedora/.vnc nametype=CREATE cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(01/12/2023 02:58:12.648:696) : item=0 name=/home/fedora/ inode=262145 dev=fc:02 mode=dir,700 ouid=fedora ogid=fedora rdev=00:00 obj=unconfined_u:object_r:user_home_dir_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(01/12/2023 02:58:12.648:696) : cwd=/home/fedora type=SYSCALL msg=audit(01/12/2023 02:58:12.648:696) : arch=x86_64 syscall=mkdir success=no exit=EACCES(Permission denied) a0=0x7fff47d52540 a1=0755 a2=0x0 a3=0x0 items=2 ppid=2869 pid=2880 auid=fedora uid=fedora gid=fedora euid=fedora suid=fedora fsuid=fedora egid=fedora sgid=fedora fsgid=fedora tty=(none) ses=8 comm=vncsession exe=/usr/sbin/vncsession subj=system_u:system_r:vnc_session_t:s0 key=(null) type=AVC msg=audit(01/12/2023 02:58:12.648:696) : avc: denied { create } for pid=2880 comm=vncsession name=.vnc scontext=system_u:system_r:vnc_session_t:s0 tcontext=system_u:object_r:vnc_home_t:s0 tclass=dir permissive=0 ---- Caught in permissive mode: ---- type=PROCTITLE msg=audit(01/12/2023 02:59:45.366:718) : proctitle=/usr/sbin/vncsession fedora :1 type=PATH msg=audit(01/12/2023 02:59:45.366:718) : item=1 name=/home/fedora/.vnc inode=264342 dev=fc:02 mode=dir,755 ouid=fedora ogid=fedora rdev=00:00 obj=system_u:object_r:vnc_home_t:s0 nametype=CREATE cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(01/12/2023 02:59:45.366:718) : item=0 name=/home/fedora/ inode=262145 dev=fc:02 mode=dir,700 ouid=fedora ogid=fedora rdev=00:00 obj=unconfined_u:object_r:user_home_dir_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(01/12/2023 02:59:45.366:718) : cwd=/home/fedora type=SYSCALL msg=audit(01/12/2023 02:59:45.366:718) : arch=x86_64 syscall=mkdir success=yes exit=0 a0=0x7fff4ebccc70 a1=0755 a2=0x0 a3=0x0 items=2 ppid=2914 pid=2925 auid=fedora uid=fedora gid=fedora euid=fedora suid=fedora fsuid=fedora egid=fedora sgid=fedora fsgid=fedora tty=(none) ses=10 comm=vncsession exe=/usr/sbin/vncsession subj=system_u:system_r:vnc_session_t:s0 key=(null) type=AVC msg=audit(01/12/2023 02:59:45.366:718) : avc: denied { create } for pid=2925 comm=vncsession name=.vnc scontext=system_u:system_r:vnc_session_t:s0 tcontext=system_u:object_r:vnc_home_t:s0 tclass=dir permissive=1 ---- # rpm -qa selinux\* tigervnc\* | sort selinux-policy-37.17-1.fc37.noarch selinux-policy-targeted-37.17-1.fc37.noarch tigervnc-license-1.12.0-7.fc37.noarch tigervnc-selinux-1.12.0-7.fc37.noarch tigervnc-server-1.12.0-7.fc37.x86_64 tigervnc-server-minimal-1.12.0-7.fc37.x86_64 # matchpathcon /home/fedora/.vnc /home/fedora/.vnc unconfined_u:object_r:vnc_home_t:s0 # sesearch -s vnc_session_t -t vnc_home_t -c dir -p create -A allow polydomain polymember:dir { create relabelto setattr }; [ polyinstantiation_enabled ]:True # getsebool polyinstantiation_enabled polyinstantiation_enabled --> off # To work around the issue, you can enable the polyinstantiation_enabled boolean, but this boolean is not related to VNC, I believe. To fix the issue, a dedicated allow rule needs to be added to the vncsession policy module, which is brought by the tigervnc-selinux package. Here are the rules involved in this scenario (the ~/.vnc directory does not exist by default and the vncserver service tries to create it): # matchpathcon /home/fedora/ /home/fedora unconfined_u:object_r:user_home_dir_t:s0 # sesearch -s vnc_session_t -t user_home_dir_t -c dir -T type_transition vnc_session_t user_home_dir_t:dir auth_home_t .yubico; type_transition vnc_session_t user_home_dir_t:dir vnc_home_t .vnc; # sesearch -s vnc_session_t -t vnc_home_t -c dir -A allow polydomain polymember:dir { create relabelto setattr }; [ polyinstantiation_enabled ]:True allow polydomain polymember:dir { getattr open search }; [ polyinstantiation_enabled ]:True allow vnc_session_t vnc_home_t:dir { add_name getattr ioctl lock open read remove_name search write }; #
I unfortunately don't understand SELinux enough to be able to fix it myself. @zpytela: Zdeňku, you helped me in the past with this and fixed the policy in upstream, can you please look into what we might need to add? Has there been any change in SELinux recently? Because I thought this was working just fine. The policy is here: https://github.com/TigerVNC/tigervnc/blob/master/unix/vncserver/selinux/vncsession.te
In selinux-policy, we usually add rules so it is unlikely that some permission disappeared. I see the create permission is missing: > allow vnc_session_t vnc_home_t:dir { add_name getattr ioctl lock open read remove_name search write }; so it should suffice just to add this one. I wonder if it could be a part of userdom_user_home_dir_filetrans() and userdom_admin_home_dir_filetrans(): userdom_user_home_dir_filetrans(vnc_session_t, vnc_home_t, dir, ".vnc") filetrans_pattern($1, user_home_dir_t, $2, $3, $4) define(`filetrans_pattern',` allow $1 $2:dir rw_dir_perms; type_transition $1 $2:$4 $3 $5; ') define(`rw_dir_perms', `{ open read getattr lock search ioctl add_name remove_name write }')
(In reply to Zdenek Pytela from comment #6) > In selinux-policy, we usually add rules so it is unlikely that some > permission disappeared. > > I see the create permission is missing: > > allow vnc_session_t vnc_home_t:dir { add_name getattr ioctl lock open read remove_name search write }; > > so it should suffice just to add this one. I wonder if it could be a part of > userdom_user_home_dir_filetrans() and userdom_admin_home_dir_filetrans(): > > > userdom_user_home_dir_filetrans(vnc_session_t, vnc_home_t, dir, ".vnc") > > filetrans_pattern($1, user_home_dir_t, $2, $3, $4) > > define(`filetrans_pattern',` > allow $1 $2:dir rw_dir_perms; > type_transition $1 $2:$4 $3 $5; > ') > > define(`rw_dir_perms', `{ open read getattr lock search ioctl add_name > remove_name write }') May I kindly ask you to propose this to upstream? There is going to be a new release soon, currently beta is out and it would be great to have it in.
(In reply to Jan Grulich from comment #7) > May I kindly ask you to propose this to upstream? There is going to be a new > release soon, currently beta is out and it would be great to have it in. Sure, I just need to think through it. I actually started to make a commit when I happaned to find this little issue.
The same problem is reproducible on RHEL-8.8 and RHEL-9.2.
FEDORA-2023-cc92041f74 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-cc92041f74
FEDORA-2023-2531d96698 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-2531d96698
FEDORA-2023-cc92041f74 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-cc92041f74` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-cc92041f74 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-2531d96698 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-2531d96698 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-cc92041f74 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-e41b966de1 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-e41b966de1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-e41b966de1 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.