I'm running tests with using sssd for smartcard auth as an pam_pkcs11 replacement. I've gotten it to work, but am getting a _lot_ of selinux denials. 

It seems that p11_child inherits the sssd selinux context and therefore runs in the 'sssd_t' domain. This causes problems since p11_child seems to want access to a whole lot of stuff. Some examples:

SELinux is preventing /usr/libexec/sssd/p11_child from search access on the directory fs.
SELinux is preventing /usr/libexec/sssd/p11_child from write access on the directory /dev/hugepages.
SELinux is preventing /usr/libexec/sssd/p11_child from write access on the directory /proc/fs/nfsd.
SELinux is preventing /usr/libexec/sssd/p11_child from write access on the directory /boot.
SELinux is preventing /usr/libexec/sssd/p11_child from write access on the directory /home.
SELinux is preventing /usr/libexec/sssd/p11_child from search access on the directory /var/lib/nfs.
SELinux is preventing /usr/libexec/sssd/p11_child from write access on the directory /.
SELinux is preventing /usr/libexec/sssd/p11_child from execute access on the file /run/user/60483/ffiSOUzGu (deleted).
SELinux is preventing /usr/libexec/sssd/p11_child from write access on the directory /sys/fs/fuse/connections.
SELinux is preventing /usr/libexec/sssd/p11_child from write access on the directory /dev.
SELinux is preventing /usr/libexec/sssd/p11_child from execute access on the file /dev/shm/ffi8thWCx (deleted).
SELinux is preventing /usr/libexec/sssd/p11_child from execute access on the file /run/ffi24njzA (deleted).
SELinux is preventing /usr/libexec/sssd/p11_child from write access on the directory /sys/kernel/config.
SELinux is preventing /usr/libexec/sssd/p11_child from write access on the directory /sys/fs/selinux.


An Sealert output:

SELinux is preventing /usr/libexec/sssd/p11_child from search access on the directory .config.

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

If you believe that p11_child should be allowed search access on the .config 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 'p11_child' --raw | audit2allow -M my-p11child
# semodule -i my-p11child.pp


Additional Information:
Source Context                system_u:system_r:sssd_t:s0
Target Context                unconfined_u:object_r:config_home_t:s0
Target Objects                .config [ dir ]
Source                        p11_child
Source Path                   /usr/libexec/sssd/p11_child
Port                          <Unknown>
Host                          c21226.ad.smhi.se
Source RPM Packages           sssd-krb5-common-1.15.2-50.el7_4.6.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-166.el7_4.5.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     c21226.ad.smhi.se
Platform                      Linux c21226.ad.smhi.se 3.10.0-693.5.2.el7.x86_64
                              #1 SMP Fri Oct 13 10:46:25 EDT 2017 x86_64 x86_64
Alert Count                   29
First Seen                    2017-10-20 08:14:10 CEST
Last Seen                     2017-10-20 13:21:38 CEST
Local ID                      17d70bbe-a54d-47c3-8515-985d6646a93f

Raw Audit Messages
type=AVC msg=audit(1508498498.877:13286): avc:  denied  { search } for  pid=29036 comm="krb5_child" name=".config" dev="sda2" ino=16782181 scontext=system_u:system_r:sssd_t:s0 tcontext=unconfined_u:object_r:config_home_t:s0 tclass=dir


type=SYSCALL msg=audit(1508498498.877:13286): arch=x86_64 syscall=openat success=no exit=EACCES a0=ffffffffffffff9c a1=56536c43c350 a2=90800 a3=0 items=0 ppid=20098 pid=29036 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=krb5_child exe=/usr/libexec/sssd/krb5_child subj=system_u:system_r:sssd_t:s0 key=(null)

Hash: p11_child,sssd_t,config_home_t,dir,search



Whats with all the acceses, is that normal? And if so, how's that suppose to work while running in the 'sssd_t' context?


Regards
Adam