RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1301686 - SELinux Preventing SSSD Active Directory authentication with krb5_child
Summary: SELinux Preventing SSSD Active Directory authentication with krb5_child
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.6
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: Steeve Goveas
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-01-25 17:11 UTC by Tim Roberts
Modified: 2023-10-06 17:31 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-23 15:51:58 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Tim Roberts 2016-01-25 17:11:47 UTC 
Description of problem: When using SSSD for Active Directory authentication and SELinux in enforcing mode, SELinux prevents /usr/libexec/sssd/krb5_child from write/read access and disallows Active Directory authentication/logins.

Generating a local policy does work but I feel this shouldn't be necessary when using SSSD & Kerberos.


Version-Release number of selected component (if applicable): sssd-1.13.0-40.el7_2.1.x86_64


How reproducible: Use sssd & realmd to successfully join to and AD domain. Then reboot system and find the above errors taking place.


Additional info:

SELinux is preventing /usr/libexec/sssd/krb5_child from write access on the key Unknown.

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

If you believe that krb5_child should be allowed write access on the Unknown key 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:
# grep krb5_child /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:sssd_t:s0
Target Context                system_u:system_r:kernel_t:s0
Target Objects                Unknown [ key ]
Source                        krb5_child
Source Path                   /usr/libexec/sssd/krb5_child
Port                          <Unknown>
Host                          <our internal hostname>
Source RPM Packages           sssd-krb5-common-1.13.0-40.el7_2.1.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-60.el7.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     <our internal hostname>
Platform                      Linux <our internal hostname>
                              3.10.0-327.4.4.el7.x86_64 #1 SMP Thu Dec 17
                              15:51:24 EST 2015 x86_64 x86_64
Alert Count                   9
First Seen                    2016-01-21 16:57:23 EST
Last Seen                     2016-01-21 17:00:09 EST
Local ID                      2b7ad414-3e01-4953-9294-3b87c8a9c60c

Raw Audit Messages
type=AVC msg=audit(1453413609.693:568): avc:  denied  { write } for  pid=3469 comm="krb5_child" scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=key


type=SYSCALL msg=audit(1453413609.693:568): arch=x86_64 syscall=add_key success=no exit=EACCES a0=7fd43f7d4fdc a1=7ffd3d9dc610 a2=0 a3=0 items=0 ppid=745 pid=3469 auid=4294967295 uid=1548281918 gid=1548200513 euid=1548281918 suid=1548281918 fsuid=1548281918 egid=1548200513 sgid=1548200513 fsgid=1548200513 tty=(none) ses=4294967295 comm=krb5_child exe=/usr/libexec/sssd/krb5_child subj=system_u:system_r:sssd_t:s0 key=(null)

Hash: krb5_child,sssd_t,kernel_t,key,write
Comment 2 Lukas Slebodnik 2016-01-25 18:07:46 UTC 
(In reply to Tim Roberts from comment #0)
> type=SYSCALL msg=audit(1453413609.693:568): arch=x86_64 syscall=add_key
> success=no exit=EACCES a0=7fd43f7d4fdc a1=7ffd3d9dc610 a2=0 a3=0 items=0
> ppid=745 pid=3469 auid=4294967295 uid=1548281918 gid=1548200513
> euid=1548281918 suid=1548281918 fsuid=1548281918 egid=1548200513
> sgid=1548200513 fsgid=1548200513 tty=(none) ses=4294967295 comm=krb5_child
> exe=/usr/libexec/sssd/krb5_child subj=system_u:system_r:sssd_t:s0 key=(null)
> 
It seems to be related to kernel keyring (syscall=add_key)

I would like to see a log file from sssd.
Could you :
* put "debug_level = 9" into domain section of sssd.conf
* restart sssd
* reproduce issue
* attach file https://fedorahosted.org/sssd/wiki/Troubleshooting
Comment 3 Jakub Hrozek 2016-02-03 17:32:42 UTC 
ping; any luck getting those logs?
Comment 4 Jakub Hrozek 2016-02-16 15:06:13 UTC 
This bug was needinfo'd for a month. I'm going to close it with insufficient data, please reopen if the problem still persists and you can provide the information requested in comment #2.
Comment 5 Orion Poplawski 2019-01-01 22:59:05 UTC 
Just ran into this for the first time on one of our systems:

type=AVC msg=audit(1546368679.638:334966): avc:  denied  { view } for  pid=170392 comm="krb5_child" scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=key permissive=0
type=AVC msg=audit(1546368679.638:334967): avc:  denied  { write } for  pid=170392 comm="krb5_child" scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=key permissive=0

Jan 01 10:51:19 kronos.mry.nwra.com [sssd[krb5_child[170392]]][170392]: Permission denied

In permissive I see:

type=AVC msg=audit(1546383013.801:337182): avc:  denied  { write } for  pid=252969 comm="sshd" name="nssdb" dev="md1" ino=268968780 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1546383014.773:337192): avc:  denied  { append } for  pid=253036 comm="selinux_child" path="socket:[105799]" dev="sockfs" ino=105799 scontext=system_u:system_r:sssd_selinux_manager_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket permissive=1

selinux-policy-3.13.1-229.el7_6.6.noarch
sssd-1.16.2-13.el7_5.nwra.1.x86_64

After switching to permissive mode I can no longer reproduce the krb5_child error.  I'm afraid I was only at debug level 5 and so only got the above krb5_child output.

(Tue Jan  1 10:51:19 2019) [sssd[be[nwra.com]]] [krb5_auth_done] (0x0040): The krb5_child process returned an error. Please inspect the krb5_child.log file or the journal for more information
Comment 6 Orion Poplawski 2019-01-02 19:06:04 UTC 
krb5_child log:

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562608: Response was from master KDC

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562609: Decoding FAST response

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562610: FAST reply key: aes256-cts/17EF

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562611: TGS reply is for USER.COM -> host/client.example.com with session key aes256-cts/BCCB

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562612: TGS request result: 0/Success

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562613: Received creds for desired service host/client.example.com

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562614: Storing USER.COM -> host/client.example.com in MEMORY:ifSvQRl

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562615: Creating authenticator for USER.COM -> host/client.example.com, seqnum 0, subkey (null), session key aes256-cts/BCCB

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562617: Retrieving host/client.example.com from MEMORY:/etc/krb5.keytab (vno 1, enctype aes256-cts) with result: 0/Success

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562618: Decrypted AP-REQ with specified server principal host/client.example.com: aes256-cts/1062

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562619: AP-REQ ticket: USER.COM -> host/client.example.com, session key aes256-cts/BCCB

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562620: Negotiated enctype based on authenticator: aes256-cts

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562621: Initializing MEMORY:rd_req2 with default princ USER.COM

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562622: Storing USER.COM -> host/client.example.com in MEMORY:rd_req2

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562623: Storing USER.COM -> krbtgt/EXAMPLE.COM.COM in MEMORY:rd_req2

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562624: Destroying ccache MEMORY:ifSvQRl

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [validate_tgt] (0x0400): TGT verified using key for [host/client.example.com].
(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562625: Retrieving USER.COM -> host/client.example.com from MEMORY:rd_req2 with result: 0/Success

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562626: Retrieving host/client.example.com from MEMORY:/etc/krb5.keytab (vno 1, enctype aes256-cts) with result: 0/Success

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_send_pac] (0x0400): PAC responder contacted. It might take a bit of time in case the cache is not up to date.
(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_child_krb5_trace_cb] (0x4000): [222800] 1546454807.562627: Destroying ccache MEMORY:rd_req2

(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_get_ccache_name_for_principal] (0x4000): Location: [KEYRING:persistent:21662]
(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [sss_get_ccache_name_for_principal] (0x2000): krb5_cc_cache_match failed: [-1765328243][Can't find client principal USER.COM in cache collection]
(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [create_ccache] (0x4000): Initializing ccache of type [KEYRING]
(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [create_ccache] (0x4000): CC supports switch
(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [create_ccache] (0x4000): Match not found
(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [create_ccache] (0x4000): krb5_cc_cache_match failed
(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [create_ccache] (0x0020): 1007: [13][Permission denied]
(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [map_krb5_error] (0x0020): 1808: [13][Permission denied]
(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [k5c_send_data] (0x0200): Received error code 1432158209
(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [pack_response_packet] (0x2000): response packet size: [20]
(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [k5c_send_data] (0x4000): Response sent.
(Wed Jan  2 10:46:47 2019) [[sssd[krb5_child[222800]]]] [main] (0x0400): krb5_child completed successfully
Comment 7 Sumit Bose 2019-01-22 13:36:33 UTC 
Hi,

since you are using the KEYRING type credential cache SSSD needs to have access to the kernel keyring. So sssd_t as source and kernel_t as target make sense. However, while lookup at the existing related rules:

# sesearch -s sssd_t  -c key -A
Found 7 semantic av rules:
   allow domain domain : key { search link } ; 
   allow sssd_t sssd_t : key { view read write search link setattr create } ; 
   allow sssd_t nsswitch_domain : key { view read write search link setattr create } ; 
   allow sssd_t login_pgm : key { view read write search link setattr create } ; 
   allow nsswitch_domain sssd_t : key { view read write search link setattr create } ; 
   allow nsswitch_domain userdomain : key { view read write search link setattr create } ; 
   allow sssd_t userdomain : key { view read write search link setattr create } ; 


There are some rules which allow access but none with target kernel_t.

Petr, do you know how the kernel keyring is protected by SELiunx and which rule should allow SSSD to write keys for a user?

Thanks.

bye,
Sumit
Comment 8 Ondrej Mosnacek 2019-01-23 09:21:11 UTC 
Based on what I can read from the logs provided by Orion (and from sssd/Kerberos source code), sssd tries to access the persistent keyring for UID 21662 ("Location: [KEYRING:persistent:21662]"). It is not clear to me what process first accessed this keyring (it should be created when first requested by a process according to 'man persistent-keyring'), when this happened, and why it got labeled as kernel_t (it should get labeled after the process that created it). We need to find answers to these questions before we can determine where the root of the problem is and how to fix it.
Comment 9 Sumit Bose 2019-01-28 11:11:15 UTC 
Hi,

thank you Ondrej, this makes sense.

@Orion, are you using NFS or CIFS kernel modules on the system where you have seen the AVC which might request Kerberos tickets with kernel_t ?

bye,
Sumit
Comment 11 Orion Poplawski 2019-01-28 15:45:39 UTC 
We make extensive use of NFS, and a smattering of CIFS.  On kronos, the machine where we first saw this issue we make fairly heavy use of CIFS, so that may be the source.
Comment 16 kludhwan 2019-08-20 16:20:59 UTC 
Hello Sumit,

Thanks i have shared the suggestion with customer but just want to understand if we create custom policy and add it to selinux rules but will that we override if we will update the package of selinux-policy?

Thanks,
Kushal
Comment 17 Sumit Bose 2019-08-21 06:15:36 UTC 
(In reply to kludhwan from comment #16)
> Hello Sumit,
> 
> Thanks i have shared the suggestion with customer but just want to
> understand if we create custom policy and add it to selinux rules but will
> that we override if we will update the package of selinux-policy?

Hi,

please see the audit2allow man page:
"""
...
       ******************** IMPORTANT ***********************

       In order to load this newly created policy package into the kernel,
       you are required to execute

       semodule -i local.pp
...
"""

So you have to load the policy explicitly after every reboot an update of the selinux-policy package would not change this. Please ask the SELinux maintainers what is the recommend way to load the local policies during reboot.

HTH

bye,
Sumit

> 
> Thanks,
> Kushal
Comment 18 Orion Poplawski 2019-08-21 15:25:58 UTC 
Once a custom module is loaded, it is persistent across reboots.
Comment 22 marco köhl 2020-02-07 07:30:48 UTC 
Hi,

currently we are experiencing the same problem. I managed to create a pp-File as a workaround, but I feel this is not the best way for future Updates/Installations.

Is there any work in progress in this case?

Cheers

Marco
Comment 23 Sumit Bose 2020-02-12 09:15:34 UTC 
Hi,

so, if the kernel keyring is used to store the Kerberos credential cache (ccache type KEYRING) and some kernel modules like cifs or nfs have created the keyring for the user before, it is labeled with system_u:system_r:kernel_t:s0 which makes sense because a kernel module created it.system_u:system_r:kernel_t:s0

In the default policy SSSD is not allowed to access it. Imo just changing the default policy to allow this might be a bit too broad.

Ondrej, do you think it would be possible to add a SELinux boolean which can be enabled on system where SSSD has to access keyrings labeled with system_u:system_r:kernel_t:s0 but is disabled by default?

bye,
Sumit
Comment 26 Tomas Halman 2020-03-23 15:51:58 UTC 
This is not SSSD bug but the issue is in selinux, closing
Comment 27 Orion Poplawski 2020-03-23 16:56:15 UTC 
Shouldn't this be addressed in SELinux rather than just closing?
Comment 28 Sumit Bose 2020-03-23 17:14:15 UTC 
(In reply to Orion Poplawski from comment #27)
> Shouldn't this be addressed in SELinux rather than just closing?

ah, sorry, SELinux ticket is https://bugzilla.redhat.com/show_bug.cgi?id=1802062.

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