Description of problem: I'm trying out the Fedora 38 beta, and am having problems mounting some CIFS shares. Some mounts work and some don't. I'm not sure why, since the calls seem similar enough on the client end, but maybe the servers are different. The commands I run (which are copied unmodified from my working Fedora 37 client) are all of the form: mount -t cifs -o ip=A.B.C.D,vers=3.0,username=my_ad_user,domain=AD,uid=my_local_user,file_mode=0600,dir_mode=0700 //server/share /mnt/mount_point to different servers and shares. For the ones that don't work, I get this error back from mount: mount error(126): Required key not available Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) with `dmesg` just containing the same error code 126, and the following AVC denies: root ~ # ausearch -c 'request-key' | tail -n 12 ---- time->Mon Mar 27 13:47:19 2023 type=AVC msg=audit(1679917639.918:3356): avc: denied { execute } for pid=185709 comm="request-key" name="key.dns_resolver" dev="dm-0" ino=117500121 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file permissive=0 ---- time->Mon Mar 27 13:47:19 2023 type=AVC msg=audit(1679917639.918:3357): avc: denied { execute } for pid=185710 comm="request-key" name="key.dns_resolver" dev="dm-0" ino=117500121 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file permissive=0 ---- time->Mon Mar 27 13:47:19 2023 type=AVC msg=audit(1679917639.918:3358): avc: denied { read } for pid=185709 comm="request-key" name="log" dev="devtmpfs" ino=205 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:devlog_t:s0 tclass=lnk_file permissive=0 ---- time->Mon Mar 27 13:47:19 2023 type=AVC msg=audit(1679917639.918:3359): avc: denied { read } for pid=185710 comm="request-key" name="log" dev="devtmpfs" ino=205 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:devlog_t:s0 tclass=lnk_file permissive=0 Whether or not I include the IP address as an option to `mount` makes no difference. Bug 2166228 talks about other errors on /sbin/request-key, but that bug was supposed to be fixed in selinux-policy-38.8-2.fc38, and I'm still seeing it in selinux-policy-38.9-1.fc38. The errors in that bug also all refer to kernel_generic_helper_t, but mine are keyutils_request_t. Version-Release number of selected component (if applicable): selinux-policy-38.9-1.fc38.noarch Additional info: root ~ # ausearch -c 'request-key' | audit2allow #============= keyutils_request_t ============== allow keyutils_request_t bin_t:file execute; allow keyutils_request_t devlog_t:lnk_file read; root ~ # sestatus -v SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 Process contexts: Current context: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Init context: system_u:system_r:init_t:s0 File contexts: Controlling terminal: unconfined_u:object_r:user_devpts_t:s0 /etc/passwd system_u:object_r:passwd_file_t:s0 /etc/shadow system_u:object_r:shadow_t:s0 /bin/bash system_u:object_r:shell_exec_t:s0 /bin/login system_u:object_r:login_exec_t:s0 /bin/sh system_u:object_r:bin_t:s0 -> system_u:object_r:shell_exec_t:s0 /sbin/agetty system_u:object_r:getty_exec_t:s0 /sbin/init system_u:object_r:bin_t:s0 -> system_u:object_r:init_exec_t:s0 /usr/sbin/sshd system_u:object_r:sshd_exec_t:s0
Hi. Now that F38 has been released more people are going to be hitting this. Can we look at maybe getting it fixed soon?
Can anyone provide a minimal reproducer? None of us is familiar with CIFS and this would be very hard to fix without a reproducer.
(In reply to Ondrej Mosnáček from comment #2) > Can anyone provide a minimal reproducer? None of us is familiar with CIFS > and this would be very hard to fix without a reproducer. Unfortunately me neither. I've never looked at the server side of CIFS, and only know that this mount is required to access some shares at work. "smbclient" can connect to all shares when run from the CLI. I have looked at "smbclient --debuglevel=10" for both CIFS shares that I can mount and ones that I can't, and the only difference that looks relevant is that those that are mountable only mention //fileserver.dnsdomain/share, whereas the ones that aren't first mention //dnsdomain/share and then //fileserver-dfs.dnsdomain/share. The string "DFS" look significant: https://learn.microsoft.com/en-us/windows/win32/dfs/distributed-file-system I know even less about SELinux, but I do have a lab system and time available to test proposed changes.
This may be related to https://bugzilla.redhat.com/show_bug.cgi?id=2188074
So far I have only seen DFS names fail to mount (and regular CIFS/SMB shares mount fine). Reproduction therefore seems to require DFS but obtaining access to a DFS share is not trivial. AWS FSx does support creation of such shares and so that is one avenue. My understanding of DFS is very limited but I know that in my testing using vanilla systemd defined mounts I can generate success/failure at will by using a dfs-share-name or not. So, for example mounting: * //same-exact-server/dfs-share-name/same-folder/sub-folder (failure) * //same-exact-server/same-folder/sub-folder For the record when disabling SELinux to complete the mount of dfs-share-name and then comparing mount of a non-DFS share all detailed mount attributes are the same. This is not surprising because SELinux issues seem to be about denials when accessing creds for the dfs-share-name. Also, another separate report of this issue again referencing DFS: https://discussion.fedoraproject.org/t/fc38-mount-cifs-mount-smb-mount-smb3-error-126/81271
*** Bug 2188474 has been marked as a duplicate of this bug. ***
*** Bug 2188074 has been marked as a duplicate of this bug. ***
I am still unable to reproduce the reported problems, but submitted a PR towards resolving. Please try the following scratchbuild: https://github.com/fedora-selinux/selinux-policy/pull/1672 Checks -> Artifacts -> rpms.zip and gather AVC denials after reproducing the problem: ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today
(In reply to Zdenek Pytela from comment #8) > Please try the following scratchbuild: > > https://github.com/fedora-selinux/selinux-policy/pull/1672 > Checks -> Artifacts -> rpms.zip I installed those RPM:s: # rpm -qa | grep selinux-policy selinux-policy-38.12-1.20230504_210728.38ccdd1.fc39.noarch selinux-policy-targeted-38.12-1.20230504_210728.38ccdd1.fc39.noarch rebooted, and tried to mount my DFS file system. I did not get the same errors as before, but instead a new one (and the mount still failed): # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today ---- type=AVC msg=audit(2023-05-05 10:31:49.674:223) : avc: denied { execute_no_trans } for pid=5081 comm=request-key path=/usr/sbin/key.dns_resolver dev="dm-0" ino=117500121 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:keyutils_request_exec_t:s0 tclass=file permissive=0 ---- type=AVC msg=audit(2023-05-05 10:31:49.676:224) : avc: denied { execute_no_trans } for pid=5082 comm=request-key path=/usr/sbin/key.dns_resolver dev="dm-0" ino=117500121 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:keyutils_request_exec_t:s0 tclass=file permissive=0
Thank you, I've updated the PR, the package will be updated shortly, too. Is there any failure reason written in the journal?
I can't find anything obviously interesting in the journal, just a generic error code 126 that is the same as before: maj 05 10:31:48 fedora38 sudo[5076]: pam_unix(sudo:session): session opened for user root(uid=0) by creideiki(uid=1000) maj 05 10:31:48 fedora38 audit[5076]: USER_START pid=5076 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success' maj 05 10:31:49 fedora38 kernel: CIFS: Attempting to mount \\REDACTED maj 05 10:31:49 fedora38 audit[5081]: AVC avc: denied { execute_no_trans } for pid=5081 comm="request-key" path="/usr/sbin/key.dns_resolver" dev="dm-0" ino=117500121 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:keyutils_request_exec_t:s0 tclass=file permissive=0 maj 05 10:31:49 fedora38 request-key[5081]: :42: Failed to execute '/sbin/key.dns_resolver': Permission denied maj 05 10:31:49 fedora38 request-key[5082]: :42: Failed to execute '/sbin/key.dns_resolver': Permission denied maj 05 10:31:49 fedora38 audit[5082]: AVC avc: denied { execute_no_trans } for pid=5082 comm="request-key" path="/usr/sbin/key.dns_resolver" dev="dm-0" ino=117500121 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:keyutils_request_exec_t:s0 tclass=file permissive=0 maj 05 10:31:49 fedora38 kernel: CIFS: VFS: cifs_mount failed w/return code = -126 maj 05 10:31:49 fedora38 sudo[5076]: pam_unix(sudo:session): session closed for user root I upgraded to the latest versions: $ rpm -qa | grep selinux-policy selinux-policy-38.12-1.20230505_094641.5720378.fc39.noarch selinux-policy-targeted-38.12-1.20230505_094641.5720378.fc39.noarch After that (without rebooting), mounting the DFS share works.
Unfortunately, I'm still getting the same issues. $ rpm -qa | grep ^selinux selinux-policy-38.12-1.20230505_094641.5720378.fc39.noarch selinux-policy-targeted-38.12-1.20230505_094641.5720378.fc39.noarch $ sudo journalctl -b | grep enied May 07 13:48:02 test-server audit[1396]: AVC avc: denied { execute } for pid=1396 comm="request-key" name="cifs.upcall" dev="sda4" ino=3836882 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file permissive=0 May 07 13:48:02 test-server request-key[1396]: :42: Failed to execute '/usr/sbin/cifs.upcall': Permission denied I re-validated that the mount still does succeed in permissive mode with `sudo setenforce 0; sudo systemctl restart var-mnt.service`
It looks like an old journal entry or something went wrong with the update: f38# ls -lZ /usr/sbin/cifs.upcall -rwxr-xr-x. 1 root root system_u:object_r:keyutils_request_cifs_exec_t:s0 45368 Jan 31 19:00 /usr/sbin/cifs.upcall f38# matchpathcon /usr/sbin/cifs.upcall /usr/sbin/cifs.upcall system_u:object_r:keyutils_request_cifs_exec_t:s0 If your output is different, run f38# restorecon -v /usr/sbin/cifs.upcall and repeat.
*** Bug 2190331 has been marked as a duplicate of this bug. ***
After upgrading my Fedora 38 system (still on selinux-policy{,-targeted}-38.12-1.20230505_094641.5720378.fc39.noarch) and rebooting for CVE-2023-32233, my DFS mounts still work, but now give me these errors: # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today ---- type=AVC msg=audit(2023-05-15 10:22:02.731:236) : avc: denied { getattr } for pid=6910 comm=key.dns_resolve path=/etc/resolv.conf dev="dm-0" ino=150996037 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:net_conf_t:s0 tclass=file permissive=0 ---- type=AVC msg=audit(2023-05-15 10:22:02.731:237) : avc: denied { read } for pid=6910 comm=key.dns_resolve name=resolv.conf dev="dm-0" ino=150996037 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:net_conf_t:s0 tclass=file permissive=0 ---- type=AVC msg=audit(2023-05-15 10:22:02.731:238) : avc: denied { read } for pid=6910 comm=key.dns_resolve name=hosts dev="dm-0" ino=150995210 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:net_conf_t:s0 tclass=file permissive=0 # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today | audit2allow #============= keyutils_request_t ============== allow keyutils_request_t net_conf_t:file { getattr read }; This is apparently not critical, since the file systems are mounted and accessible, but the SELinux Troubleshooter popup is somewhat disconcerting.
(In reply to Zdenek Pytela from comment #14) > It looks like an old journal entry or something went wrong with the update: > > f38# ls -lZ /usr/sbin/cifs.upcall > -rwxr-xr-x. 1 root root system_u:object_r:keyutils_request_cifs_exec_t:s0 > 45368 Jan 31 19:00 /usr/sbin/cifs.upcall > f38# matchpathcon /usr/sbin/cifs.upcall > /usr/sbin/cifs.upcall system_u:object_r:keyutils_request_cifs_exec_t:s0 > > If your output is different, run > f38# restorecon -v /usr/sbin/cifs.upcall > > and repeat. The way I am having to test this on FedoraCoreOS is a little complicated and so I'm not sure my tests are valid. In any case as I look at SELinux settings they are indeed not what you anticipate, but the installed policy doesn't seem to specify what you expect either. % ls -lZ /usr/sbin/cifs.upcall -rwxr-xr-x. 3 root root system_u:object_r:bin_t:s0 45368 Jan 1 1970 /usr/sbin/cifs.upcall % matchpathcon /usr/sbin/cifs.upcall /usr/sbin/cifs.upcall system_u:object_r:bin_t:s0 More detail on how I'm running this test here: https://github.com/coreos/fedora-coreos-tracker/issues/1447 This is the selinux policy installed: rpm -qa | grep ^selinux selinux-policy-38.12-1.20230505_094641.5720378.fc39.noarch selinux-policy-targeted-38.12-1.20230505_094641.5720378.fc39.noarch
*** Bug 2208066 has been marked as a duplicate of this bug. ***
*** Bug 2208106 has been marked as a duplicate of this bug. ***
(In reply to Zdenek Pytela from comment #8) > https://github.com/fedora-selinux/selinux-policy/pull/1672 > Checks -> Artifacts -> rpms.zip > > and gather AVC denials after reproducing the problem: > > ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today After installing the files on rpms.zip there are 3 NEW different SELinux AVC. The first is occurs twice, the second once and the third twice. This set of 5 AVS repeats every 10 minutes. The last set is writen bellow ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today Shows: type=AVC msg=audit(05/19/23 16:38:24.154:238) : avc: denied { read } for pid=6005 comm=key.dns_resolve name=resolv.conf dev="dm-0" ino=84150276 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:net_conf_t:s0 tclass=lnk_file permissive=0 ---- type=AVC msg=audit(05/19/23 16:38:24.154:239) : avc: denied { read } for pid=6005 comm=key.dns_resolve name=resolv.conf dev="dm-0" ino=84150276 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:net_conf_t:s0 tclass=lnk_file permissive=0 ---- type=AVC msg=audit(05/19/23 16:38:24.154:240) : avc: denied { read } for pid=6005 comm=key.dns_resolve name=hosts dev="dm-0" ino=84148596 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=unconfined_u:object_r:net_conf_t:s0 tclass=file permissive=0 ---- type=AVC msg=audit(05/19/23 16:38:24.154:241) : avc: denied { create } for pid=6005 comm=key.dns_resolve scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:system_r:keyutils_request_t:s0 tclass=udp_socket permissive=0 ---- type=AVC msg=audit(05/19/23 16:38:24.154:242) : avc: denied { create } for pid=6005 comm=key.dns_resolve scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:system_r:keyutils_request_t:s0 tclass=udp_socket permissive=0 Let me know if I should report each bug (as they are consequence of the actions take to fix this one, and probably you already saw them)
(In reply to Zdenek Pytela from comment #14) Forgot to mention: The topics described in comment #14 did NOT work initially. They were fixed after applying the rpms.zip of topic14 (but then there were the new issues I reported above.
(In reply to Hilário Fochi Silveira from comment #21) > (In reply to Zdenek Pytela from comment #14) > Forgot to mention: > The topics described in comment #14 did NOT work initially. > They were fixed after applying the rpms.zip of topic14 > (but then there were the new issues I reported above. Thank you, try please the updated rpms.zip or today's rawhide build of selinux-policy, F38 will be updated later this week.
*** Bug 2209654 has been marked as a duplicate of this bug. ***
Testing on FCOS with latest rawhide CIFS/DFS mount succeeds but there are SELinux denials albeit somehow flagged as `permissive=1`. Is this expected? More here: https://github.com/coreos/fedora-coreos-tracker/issues/1447#issuecomment-1561673288
*** Bug 2210107 has been marked as a duplicate of this bug. ***
Tests repeated with latest rawhide build including selinux-policy-38.15-1.fc39.noarch with continued SELinux denials on attempts to perform a mount of a DFS resource. Also now noted that there is a separate mount-related issue that has also been introduced in f38 at the same time as this issue relating to kerberos tickets. Use of kerberos tickets in mounts even on non-DFS resources yields a SELinux denial. I've separated which SELinux denials arise as a result of this with more details here: https://github.com/coreos/fedora-coreos-tracker/issues/1447#issuecomment-1584727965
FEDORA-2023-9050c32c92 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-9050c32c92
FEDORA-2023-9050c32c92 has been pushed to the Fedora 38 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-9050c32c92` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-9050c32c92 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Running selinux-policy-38.17-1.fc38.noarch and selinux-policy-targeted-38.17-1.fc38.noarch from https://bodhi.fedoraproject.org/updates/FEDORA-2023-9050c32c92, my DFS mounts now fail with: # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today ---- type=AVC msg=audit(2023-06-16 16:22:41.722:806) : avc: denied { entrypoint } for pid=79110 comm=request-key path=/usr/sbin/key.dns_resolver dev="dm-0" ino=117500121 scontext=system_u:system_r:keyutils_dns_resolver_t:s0 tcontext=system_u:object_r:keyutils_dns_resolver_exec_t:s0 tclass=file permissive=0 ---- type=AVC msg=audit(2023-06-16 16:22:41.724:807) : avc: denied { entrypoint } for pid=79111 comm=request-key path=/usr/sbin/key.dns_resolver dev="dm-0" ino=117500121 scontext=system_u:system_r:keyutils_dns_resolver_t:s0 tcontext=system_u:object_r:keyutils_dns_resolver_exec_t:s0 tclass=file permissive=0
Should be fixed in the next build: https://github.com/fedora-selinux/selinux-policy/pull/1748 You can try the scratchbuild: Checks -> Artifacts -> rpms.zip
FEDORA-2023-9050c32c92 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Zdenek Pytela from comment #30) > Should be fixed in the next build: > https://github.com/fedora-selinux/selinux-policy/pull/1748 > You can try the scratchbuild: > Checks -> Artifacts -> rpms.zip I confirm that with this version (selinux-policy{,-targeted}-38.17-1.20230617_093045.530d5b8.fc39.noarch) my DFS mounts work.
*** Bug 2214081 has been marked as a duplicate of this bug. ***
Tests repeated with latest FCOS rawhide build (39.20230620.91.0) including selinux-policy-38.15-1.fc39.noarch see the same SELinux denials on attempts to perform a mount of a DFS resource. Another user has also replicated this as detailed: https://github.com/coreos/fedora-coreos-tracker/issues/1447#issuecomment-1598729706 Noting also that the separate but related f38 introduced sysadmin SELinux denial related to use of kerberos tickets persists.
(In reply to fifofonix from comment #34) > Tests repeated with latest FCOS rawhide build (39.20230620.91.0) including > selinux-policy-38.15-1.fc39.noarch see the same SELinux denials on attempts > to perform a mount of a DFS resource. I believe 39.20230620.91.0 has selinux-policy-38.17-1.fc39. Can you verify you were on 39.20230620.91.0 ?
Yes, sorry that was a copy/paste typo. I was using selinux-policy-38.17-1.fc39.noarch. Apologies. $ sudo rpm-ostree status State: idle Deployments: fedora:fedora/x86_64/coreos/rawhide Version: 39.20230620.91.0 (2023-06-20T12:46:04Z) BaseCommit: 0a2ae5f535c3f3062a7181e6223cfea0929735eb9a226f6afa1e798acd79dc47 GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C Diff: 10 added LayeredPackages: open-vm-tools ● fedora:fedora/x86_64/coreos/rawhide Version: 39.20230620.91.0 (2023-06-20T12:46:04Z) Commit: 0a2ae5f535c3f3062a7181e6223cfea0929735eb9a226f6afa1e798acd79dc47 GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C $ rpm -qa | grep ^selinux selinux-policy-38.17-1.fc39.noarch selinux-policy-targeted-38.17-1.fc39.noarch