(In reply to Amith from comment #0)
> Description of problem:
> This is related to regression run failure in krb-provider/credential_cache
> test suite. The failed case checks for enumeration and file permissions
> after setting "krb5_ccachedir = /tmp/krb5_cache_%h" in sssd.conf file. The
> user authentication step fails with AVC denial error. The SSSD service also
> fails to create /tmp/krb5_cache_/home directory which is expected. 
> 
> AVC Denial error:
> -----------------
> 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:      31
> selinux-policy-3.14.1-48.el8.noarch
> ----
> time->Fri Nov 30 10:06:04 2018
> type=PROCTITLE msg=audit(1543590364.663:868):
> proctitle=2F7573722F6C69626..........4D
> type=SYSCALL msg=audit(1543590364.663:868): arch=c000003e syscall=83
> success=no exit=-13 a0=555b01743400 a1=1c0 a2=e791240f3e123700 a3=0 items=0
> ppid=16887 pid=16927 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)
> 
> type=AVC msg=audit(1543590364.663:868): avc:  denied  { dac_override } for 
> pid=16927 comm="krb5_child" capability=1 
> scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:system_r:sssd_t:s0
> tclass=capability permissive=0

Geting rid of capability dac_override for unprivileged user is not trivial task in sssd code. I would recommend to move this BZ to the selinux-policy and allow it there. (which is one-liner comparing to changes needed in sssd)

Yes, I agree. btw this source comment should also hopefully give some context as about why is the krb5 ccache directory creation still done as root even though most of the krb5_child process runs as the user themselves:

2982 /* Pre-creating the ccache must be done as root, otherwise we can't mkdir        
2983  * some of the DIR: cache components. One example is /run/user/$UID because      
2984  * logind doesn't create the directory until the session phase, whereas          
2985  * we need the directory during the auth phase already                           
2986  */
2987     ret = k5c_precreate_ccache(kr, offline);

It's an edge case, but it's expected..

TBH I think using "krb5_ccachedir = /tmp/krb5_cache_%h" is a misuse of the '%h' template and all what should be done is to enhance the man page to explain better when to use '%h' and that it might be necessary to add parent directories when using krb5_ccachedir depending on the security setting of the system.

I think it is not worth to allow dac_override here.

my 2ct

bye,
Sumit

(In reply to Sumit Bose from comment #3)
> TBH I think using "krb5_ccachedir = /tmp/krb5_cache_%h" is a misuse of the
> '%h' template and all what should be done is to enhance the man page to
> explain better when to use '%h' and that it might be necessary to add parent
> directories when using krb5_ccachedir depending on the security setting of
> the system.
> 

This is also a possibility. It looks like the dac_override is emitted when there is a nested directory hierarchy, so even /tmp/krb5ccdir_$realm/$user produces the  AVC which makes sense because the directory is created, chowned and then krb5_child running as root tries to create the subdirectory.

Do you think a warning that a nested hierarchy might cause issues with systems like SELinux might be good enough?

> I think it is not worth to allow dac_override here.

In general I agree after your comment that we shouldn't relax the security to support a corner case with a non-default ccache use-case unless someone needs it.

(In reply to Jakub Hrozek from comment #4)
> (In reply to Sumit Bose from comment #3)
> > TBH I think using "krb5_ccachedir = /tmp/krb5_cache_%h" is a misuse of the
> > '%h' template and all what should be done is to enhance the man page to
> > explain better when to use '%h' and that it might be necessary to add parent
> > directories when using krb5_ccachedir depending on the security setting of
> > the system.
> > 
> 
> This is also a possibility. It looks like the dac_override is emitted when
> there is a nested directory hierarchy, so even /tmp/krb5ccdir_$realm/$user
> produces the  AVC which makes sense because the directory is created,
> chowned and then krb5_child running as root tries to create the subdirectory.
> 
> Do you think a warning that a nested hierarchy might cause issues with
> systems like SELinux might be good enough?

Yes, I guess (sorry, I have no data for this) that the DIR type credential cache is the less used one and might cause the most issues with respect to select and create directories. So I'd prefer to document the limitation instead of granting special privileges to get around them.

If there really is a use case which does not allow pre-creation maybe dac_override can be granted based on a SELinux boolean so that by default krb5_child does not has dac_override only if the boolean is set to True?

> 
> > I think it is not worth to allow dac_override here.
> 
> In general I agree after your comment that we shouldn't relax the security
> to support a corner case with a non-default ccache use-case unless someone
> needs it.

(In reply to Sumit Bose from comment #5)
> (In reply to Jakub Hrozek from comment #4)
> > (In reply to Sumit Bose from comment #3)
> > > TBH I think using "krb5_ccachedir = /tmp/krb5_cache_%h" is a misuse of the
> > > '%h' template and all what should be done is to enhance the man page to
> > > explain better when to use '%h' and that it might be necessary to add parent
> > > directories when using krb5_ccachedir depending on the security setting of
> > > the system.
> > > 
> > 
> > This is also a possibility. It looks like the dac_override is emitted when
> > there is a nested directory hierarchy, so even /tmp/krb5ccdir_$realm/$user
> > produces the  AVC which makes sense because the directory is created,
> > chowned and then krb5_child running as root tries to create the subdirectory.
> > 
> > Do you think a warning that a nested hierarchy might cause issues with
> > systems like SELinux might be good enough?
> 
> Yes, I guess (sorry, I have no data for this) that the DIR type credential
> cache is the less used one and might cause the most issues with respect to
> select and create directories. So I'd prefer to document the limitation
> instead of granting special privileges to get around them.
> 
> If there really is a use case which does not allow pre-creation maybe
> dac_override can be granted based on a SELinux boolean so that by default
> krb5_child does not has dac_override only if the boolean is set to True?

Hmm, maybe..? Lukas, how much work is it to add a new boolean?

Either way, I wouldn't do anything except a man page change for 8.0.

(In reply to Sumit Bose from comment #3)
> TBH I think using "krb5_ccachedir = /tmp/krb5_cache_%h" is a misuse of the
> '%h' template and all what should be done is to enhance the man page to
> explain better when to use '%h' and that it might be necessary to add parent
> directories when using krb5_ccachedir depending on the security setting of
> the system.
> 
> I think it is not worth to allow dac_override here.
> 

Sumit,
you will not hit AVC for dac_override just in this case but in lot of other cases. And solving them is not trivial with unprivileged user. (but not impossible)

Adding SELinux boolen for enabling dac_override is unnecessary complcation IMHO.
Better solution would be to enable it by default; fix sssd in next release and remove capability with fixed version of sssd.

Hi All,

Agree with Lukas, we should enable it by default.

commit f3645cfae2683684bed70cb35887162e2192c5f0 (HEAD -> rawhide)
Author: Lukas Vrabec <lvrabec@redhat.com>
Date:   Thu Dec 6 14:24:59 2018 +0100

*** Bug 1658226 has been marked as a duplicate of this bug. ***