bz 714620 fixes the selinux part, this bug is to track sssd part.

+++ This bug was initially created as a clone of Bug #714620 +++

What is the nature and description of the request?

sssd does not preform correctly when selinux = enforcing and krb5_validate =
True is used from the customer:
With selinux in enforcing mode and sssd configured with "krb5_validate = True",
subsequent authentications will fail after any single user authenticates via
GSSAPI to sshd

    Why does the customer need this? (List the business requirements here)

Would like to use sssd and selinux

    How would the customer like to achieve this? (List the functional
requirements here)

create a /var/cache/krb5cache directory, have sssd use it, set the correct
selinux permissions:
semanage fcontext -a -t krb5_host_rcache_t "/var/cache/krb5cache(/.*)?"

    For each functional requirement listed in question 4, specify how Red Hat
and the customer can test to confirm the requirement is successfully
implemented.

see above

    Is there already an existing RFE upstream or in Red Hat bugzilla?

nope

    How quickly does this need resolved? (desired target release)

minor release

    Does this request meet the RHEL Bug and Feature Inclusion Criteria (please
review)

Not specified.

    List the affected packages

selinux sssd

    Would the customer be able to assist in testing this functionality if
implemented?

yup

--- Additional comment from rdassen@redhat.com on 2011-06-20 05:36:34 EDT ---

   Who is the customer behind the request?

Account name:Georgia Institute of Tech
Customer segment:0
TAM/SRM customer yes/no:no
VHT score:0

--- Additional comment from sgallagh@redhat.com on 2011-06-20 07:11:19 EDT ---

Please include the actual AVC that was reported in audit.log.

Also, does this occur only with krb5_validate = True?

--- Additional comment from nc@redhat.com on 2011-06-20 07:40:45 EDT ---

=== In Red Hat Customer Portal Case 00447546 ===
--- Comment by Chirammal, Najmuddin on 6/20/2011 5:10 PM ---

I'm not certain whether this is an RFE for sssd or krb5 library (i guess sssd
uses krb5-libs internally).

Here are the avc denial logs, comments from customer and irc logs.

==============================
type=AVC msg=audit(1302106156.855:60229): avc:  denied  { getattr } for 
pid=1755 comm="krb5_child" path="/var/tmp/math30013-044_0" dev=sda5 ino=147459
scontext=unconfined_u:system_r:sssd_t:s0
tcontext=unconfined_u:object_r:sshd_tmp_t:s0 tclass=file
type=SYSCALL msg=audit(1302106156.855:60229): arch=c000003e syscall=6
success=no exit=-13 a0=2059520 a1=7fff40d77180 a2=7fff40d77180 a3=19 items=0
ppid=1677 pid=1755 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=160 comm="krb5_child" exe="/usr/libexec/sssd/krb5_child"
subj=unconfined_u:system_r:sssd_t:s0 key=(null)
type=AVC msg=audit(1302106156.855:60230): avc:  denied  { unlink } for 
pid=1755 comm="krb5_child" name="math30013-044_0" dev=sda5 ino=147459
scontext=unconfined_u:system_r:sssd_t:s0
tcontext=unconfined_u:object_r:sshd_tmp_t:s0 tclass=file
type=SYSCALL msg=audit(1302106156.855:60230): arch=c000003e syscall=87
success=no exit=-13 a0=2059520 a1=ffffffff a2=0 a3=19 items=0 ppid=1677
pid=1755 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=160 comm="krb5_child" exe="/usr/libexec/sssd/krb5_child"
subj=unconfined_u:system_r:sssd_t:s0 key=(null)
==============================


And the following is a brief history of the issue:

Currently sshd creates the replay cache files as /var/tmp/<rcache_file> , krb5
uses the  first service key in the keytab to validate the credentials, and the
name of that service is used to generate the name of the replay cache.

For example:

If my klist -k lists

host/example.com@EXAMPLE.COM
<some_service>/example.com@EXAMPLE.COM

then it works, (ie; it creates the rcache file as "host_0" and it works as we
have a rule defined for it. If we reverse the order, then it fails (selinux
will deny the access to the file as shown in the above selinux logs).
===================================================
<customer concern & suggestion>
It is unfortunate to see that this functionality is dependent on what should be
a meaningless ordering of the keytab. The system of course works fine with the
exception of the selinux file context not picking up on replay caches named
anything except host_0.

Obviously in its present form, the selinux policy cannot change since /var/tmp
is a free-for-all directory and no expression could reasonably catch all
possible replay cache names while missing other random temporary files.

I had been hoping the file could be changed with KRB5RCACHENAME to avoid having
such a brittle dependency on the ordering of the keytab, but it appears that
the relevant codepath does not respect the variable. However, the KRB5RCACHEDIR
environment variable is honored.

Would a viable solution be the creation of some directory specific to replay
caches (/var/cache/krb5rcache/ ?) and then having selinux label everything
inside it to krb5_host_rcache_t? This would seemingly eliminate an otherwise
brittle dependence on keytab ordering without having to update the selinux file
contexts based on the runtime rcache name.
</>

==================================================

<nc> nalin: one doubt, rcache files (under /var/tmp) are created as
/var/tmp/host_0 when I use MIT kerberos.. but when I use AD it's created as
"/var/tmp/math3000-044_0", the later one creates selinux issues.. is there a
way to force the name to be in the format /var/tmp/host_0
<nalin> nc: what process creates the replay cache?
<nc> nalin: ssh
<nalin> nc: it's using the first service key in the keytab to validate the
creds, and the name of that service is used to generate the name of the replay
cache. if you can make the first key the "host" key, that's what'll be used
<nc> nalin: If I understood correctly, I have to have "host/<hostname>" listed
first when I do a klist right?
<nalin> if you're using klist -k, then the first one you see in the list is the
one that it'll use
<nc> nalin: okay, thanks a lot.

==================================================

~Najmuddin.

--- Additional comment from rdassen@redhat.com on 2011-06-20 08:23:12 EDT ---

Hi Stephen,

Najmuddin Chirammal owns the customer case for which this feature request was
raised; please contact him for any additional data you need from the customer.

Thanks,
Ray

--- Additional comment from sbose@redhat.com on 2011-06-20 10:25:09 EDT ---

Hi Najmuddin,

I think sssd cannot do anything here. I have reassigned this bug to
selinux-policy to get the input the the SELinux developers about what would be
the right approach to solve this.

Do I understand correctly that if you add 'export
KRB5RCACHEDIR=/var/cache/krb5rcache/' as described above to the sssd start
script the issue goes away since sssd and sshd now uses separate directories
for the replay caches?

bye,
Sumit

--- Additional comment from dwalsh@redhat.com on 2011-06-22 14:34:47 EDT ---

If you add the following

# semanage fcontext -a -t krb5_host_rcache_t "/var/tmp/math30013-044_0"
# rm /var/tmp/math30013-044_0
Does everything work.

--- Additional comment from dwalsh@redhat.com on 2011-06-22 14:35:34 EDT ---

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

--- Additional comment from nc@redhat.com on 2011-07-01 05:03:31 EDT ---

(In reply to comment #5)

> Do I understand correctly that if you add 'export
> KRB5RCACHEDIR=/var/cache/krb5rcache/' as described above to the sssd start
> script the issue goes away since sssd and sshd now uses separate directories
> for the replay caches?

I'm sure that will fix the issue, currently GSSAPI creates rcache file with
wrong context (as it's not defined in policy) and for the next time (no GSSAPI,
pam_sssd used for auth) and the sssd is unable to access the file due to bad
selinux context. If sssd uses a different KRB5RCACHEDIR then the issue wont
occur but I'm not sure if using different directories for rache files crated by
krb5-libs and sssd would create any other issues.


(In reply to comment #6)
> If you add the following
> 
> # semanage fcontext -a -t krb5_host_rcache_t "/var/tmp/math30013-044_0"
> # rm /var/tmp/math30013-044_0
> Does everything work.

Yes, it'll work, the problem is is the above work only if the rcache file name
is math30013-044_0 (ie; first key(in /etc/krb5.keytab) is math30013-044, this
may vary from machine to machine).

current policy => /var/tmp/host_0  -- 
gen_context(system_u:object_r:krb5_host_rcache_t,s0)

Current policy works only if the rcache file is created with a name of host_0

As mentioned earlier, it's hard to predict the possible names with a regex, so
the customer is looking for a method in which all rcache files are created
under a specific directory (so a policy can be defined for that directory).

Note: CCing nalin, I hope he can give valuable inputs to this Feature Request.

--- Additional comment from nalin@redhat.com on 2011-07-01 15:24:08 EDT ---

(In reply to comment #8)
> (In reply to comment #5)
> 
> > Do I understand correctly that if you add 'export
> > KRB5RCACHEDIR=/var/cache/krb5rcache/' as described above to the sssd start
> > script the issue goes away since sssd and sshd now uses separate directories
> > for the replay caches?
> 
> I'm sure that will fix the issue, currently GSSAPI creates rcache file with
> wrong context (as it's not defined in policy) and for the next time (no GSSAPI,
> pam_sssd used for auth) and the sssd is unable to access the file due to bad
> selinux context. If sssd uses a different KRB5RCACHEDIR then the issue wont
> occur but I'm not sure if using different directories for rache files crated by
> krb5-libs and sssd would create any other issues.

I don't expect that to create problems -- the replay cache's job is to prevent
eavesdroppers from reusing authenticators which are sent over the network, and
SSSD is both generating and consuming them in the process of verifying that the
TGT it's just obtained isn't forged.

--- Additional comment from dwalsh@redhat.com on 2011-07-15 14:32:27 EDT ---

Are we saying this is not an SELinux policy issue then?

--- Additional comment from nalin@redhat.com on 2011-07-15 14:57:34 EDT ---

I think we're saying that having SSSD store replay caches in a non-default
location should be fine.  If there's not already a suitable location available,
then I expect we'll need policy to include the default label for a new
location.

--- Additional comment from dwalsh@redhat.com on 2011-07-15 15:23:03 EDT ---

I am willing to label /var/cache/krb5rcache/ as krb5_host_rcache_t

/var/cache/krb5rcache(/.*)?  
gen_context(system_u:object_r:krb5_host_rcache_t,s0)

--- Additional comment from ebenes@redhat.com on 2011-07-27 05:59:32 EDT ---

qa_ack+ for 6.2 selinux-policy

--- Additional comment from mgrepl@redhat.com on 2011-07-27 09:34:52 EDT ---

Fixed in selinux-policy-3.7.19-105.el6

--- Additional comment from errata-xmlrpc@redhat.com on 2011-07-29 18:44:51 EDT
---

Bug report changed to ON_QA status by Errata System.
A QE request has been submitted for advisory RHBA-2011:11350-01
http://errata.devel.redhat.com/errata/show/11350