Bug 2180634 - [Regression] SELinux is preventing SMB mounts using cached Kerberos credentials
Summary: [Regression] SELinux is preventing SMB mounts using cached Kerberos credentials
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 38
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 2180632 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-03-21 23:32 UTC by James
Modified: 2023-06-18 01:29 UTC (History)
7 users (show)

Fixed In Version: selinux-policy-38.17-1.fc38
Clone Of:
Environment:
Last Closed: 2023-06-18 01:29:51 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github fedora-selinux selinux-policy pull 1735 0 None open Allow cifs-helper read sssd kerberos configuration files 2023-06-14 09:22:42 UTC

Description James 2023-03-21 23:32:03 UTC
The general symptom is I can no longer automount a Samba share using multiuser,cruid=... with credentials in a Kerberos cache (KEYRING or KCM) because of things like:

[   41.829922] CIFS: Attempting to mount \\skipper.cb.ettle\home
[   41.863223] CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
[   41.863229] CIFS: VFS: \\skipper.cb.ettle Send error in SessSetup = -126
[   41.863239] CIFS: VFS: cifs_mount failed w/return code = -126

Full relabel doesn't help.


SELinux is preventing cifs.idmap from 'write' accesses on the sock_file /var/lib/sss/pipes/nss.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that cifs.idmap should be allowed write access on the nss sock_file 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 'cifs.idmap' --raw | audit2allow -M my-cifsidmap
# semodule -X 300 -i my-cifsidmap.pp

Additional Information:
Source Context                system_u:system_r:keyutils_request_t:s0
Target Context                system_u:object_r:sssd_var_lib_t:s0
Target Objects                /var/lib/sss/pipes/nss [ sock_file ]
Source                        cifs.idmap
Source Path                   cifs.idmap
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-38.8-2.fc38.noarch
Local Policy RPM              selinux-policy-targeted-38.8-2.fc38.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 6.2.7-300.fc38.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Fri Mar 17 16:02:49 UTC 2023
                              x86_64
Alert Count                   1
First Seen                    2023-03-21 23:24:45 GMT
Last Seen                     2023-03-21 23:24:45 GMT
Local ID                      15e3c220-f46d-47d4-8da2-43489d08e8ce

Raw Audit Messages
type=AVC msg=audit(1679441085.440:254): avc:  denied  { write } for  pid=3444 comm="cifs.idmap" name="nss" dev="dm-0" ino=94801869 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=sock_file permissive=1


Hash: cifs.idmap,keyutils_request_t,sssd_var_lib_t,sock_file,write

Comment 1 James 2023-03-21 23:37:41 UTC
There's quite a lot of alerts related to both cifs.idmap and cifs.upcall. The alert bug reporter is currently broken, but here are *some* of the ones for cifs.upcall (which is probably the main culprit):


SELinux is preventing cifs.upcall from 'connectto' accesses on the unix_stream_socket /run/.heim_org.h5l.kcm-socket.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that cifs.upcall should be allowed connectto access on the .heim_org.h5l.kcm-socket unix_stream_socket 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 'cifs.upcall' --raw | audit2allow -M my-cifsupcall
# semodule -X 300 -i my-cifsupcall.pp

Additional Information:
Source Context                system_u:system_r:keyutils_request_t:s0
Target Context                system_u:system_r:sssd_t:s0
Target Objects                /run/.heim_org.h5l.kcm-socket [ unix_stream_socket
                              ]
Source                        cifs.upcall
Source Path                   cifs.upcall
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-38.8-2.fc38.noarch
Local Policy RPM              selinux-policy-targeted-38.8-2.fc38.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 6.2.7-300.fc38.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Fri Mar 17 16:02:49 UTC 2023
                              x86_64
Alert Count                   1
First Seen                    2023-03-21 23:24:45 GMT
Last Seen                     2023-03-21 23:24:45 GMT
Local ID                      c2da35c6-5174-4184-a4e5-ec7306461c94

Raw Audit Messages
type=AVC msg=audit(1679441085.287:241): avc:  denied  { connectto } for  pid=3442 comm="cifs.upcall" path="/run/.heim_org.h5l.kcm-socket" scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:system_r:sssd_t:s0 tclass=unix_stream_socket permissive=1


Hash: cifs.upcall,keyutils_request_t,sssd_t,unix_stream_socket,connectto


SELinux is preventing cifs.upcall from 'read' accesses on the file /etc/krb5.conf.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that cifs.upcall should be allowed read access on the krb5.conf file 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 'cifs.upcall' --raw | audit2allow -M my-cifsupcall
# semodule -X 300 -i my-cifsupcall.pp

Additional Information:
Source Context                system_u:system_r:keyutils_request_t:s0
Target Context                system_u:object_r:krb5_conf_t:s0
Target Objects                /etc/krb5.conf [ file ]
Source                        cifs.upcall
Source Path                   cifs.upcall
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           krb5-libs-1.20.1-8.fc38.x86_64
                              krb5-libs-1.20.1-8.fc38.i686
SELinux Policy RPM            selinux-policy-targeted-38.8-2.fc38.noarch
Local Policy RPM              selinux-policy-targeted-38.8-2.fc38.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 6.2.7-300.fc38.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Fri Mar 17 16:02:49 UTC 2023
                              x86_64
Alert Count                   1
First Seen                    2023-03-21 23:24:45 GMT
Last Seen                     2023-03-21 23:24:45 GMT
Local ID                      0403e45c-eeee-4387-897b-a0281397bffd

Raw Audit Messages
type=AVC msg=audit(1679441085.287:235): avc:  denied  { read } for  pid=3442 comm="cifs.upcall" name="krb5.conf" dev="dm-0" ino=13428752 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:krb5_conf_t:s0 tclass=file permissive=1


Hash: cifs.upcall,keyutils_request_t,krb5_conf_t,file,read


SELinux is preventing cifs.upcall from 'read' accesses on the directory /var/lib/sss/pubconf/krb5.include.d.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that cifs.upcall should be allowed read access on the krb5.include.d 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 'cifs.upcall' --raw | audit2allow -M my-cifsupcall
# semodule -X 300 -i my-cifsupcall.pp

Additional Information:
Source Context                system_u:system_r:keyutils_request_t:s0
Target Context                system_u:object_r:sssd_public_t:s0
Target Objects                /var/lib/sss/pubconf/krb5.include.d [ dir ]
Source                        cifs.upcall
Source Path                   cifs.upcall
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           sssd-krb5-common-2.8.2-4.fc38.x86_64
SELinux Policy RPM            selinux-policy-targeted-38.8-2.fc38.noarch
Local Policy RPM              selinux-policy-targeted-38.8-2.fc38.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 6.2.7-300.fc38.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Fri Mar 17 16:02:49 UTC 2023
                              x86_64
Alert Count                   1
First Seen                    2023-03-21 23:24:45 GMT
Last Seen                     2023-03-21 23:24:45 GMT
Local ID                      4b24717d-05a8-4899-a05d-dde6d745ca49

Raw Audit Messages
type=AVC msg=audit(1679441085.287:237): avc:  denied  { read } for  pid=3442 comm="cifs.upcall" name="krb5.include.d" dev="dm-0" ino=158247 scontext=system_u:system_r:keyutils_request_t:s0 tcontext=system_u:object_r:sssd_public_t:s0 tclass=dir permissive=1


Hash: cifs.upcall,keyutils_request_t,sssd_public_t,dir,read

Comment 2 James 2023-03-23 19:26:36 UTC
This is part of the same suite as 2180608 and 2180632.

Comment 3 James 2023-03-23 19:27:59 UTC
*** Bug 2180632 has been marked as a duplicate of this bug. ***

Comment 4 Fedora Update System 2023-06-15 20:24:32 UTC
FEDORA-2023-9050c32c92 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-9050c32c92

Comment 5 Fedora Update System 2023-06-16 04:34:58 UTC
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.

Comment 6 Fedora Update System 2023-06-18 01:29:51 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.