Bug 598375 - rpc.gssd is not allowed to read kerberos credential caches created by sshd
rpc.gssd is not allowed to read kerberos credential caches created by sshd
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-01 05:04 EDT by Thomas Sailer
Modified: 2011-06-27 13:14 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 13:14:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thomas Sailer 2010-06-01 05:04:27 EDT
Description of problem:
When I log in on a client machine with sshd (and sshd kerberos authentication enabled) sshd creates a credentials cache in /tmp. Now rpc.gssd

Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.7.19-21.fc13

How reproducible:
always

Steps to Reproduce:
1.ssh user@client
  
Actual results:
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Delegating credentials
debug1: Delegating credentials
debug1: Authentication succeeded (gssapi-with-mic).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending env LANGUAGE = 
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Tue Jun  1 10:47:32 2010 from client2.xxx.com
Could not chdir to home directory /home/user: Permission denied
[user@client /]$ 

Expected results:
[user@client ~]$
(note that home directories are on nfs4 sec=krb5p servers)


Additional info:
# sealert -l 57c37d5e-73e9-4b85-a950-6a2f262ca79b

Summary:

SELinux is preventing /usr/sbin/rpc.gssd "getattr" access on
/tmp/krb5cc_10000_qyVeTx2978.

Detailed Description:

SELinux denied access requested by rpc.gssd. It is not expected that this access
is required by rpc.gssd and this access may signal an intrusion attempt. It is
also possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug
report.

Additional Information:

Source Context                system_u:system_r:gssd_t:s0
Target Context                system_u:object_r:sshd_tmp_t:s0
Target Objects                /tmp/krb5cc_10000_qyVeTx2978 [ file ]
Source                        rpc.gssd
Source Path                   /usr/sbin/rpc.gssd
Port                          <Unknown>
Host                          client.xxx.com
Source RPM Packages           nfs-utils-1.2.2-2.fc13
Target RPM Packages           
Policy RPM                    selinux-policy-3.7.19-21.fc13
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     client.xxx.com
Platform                      Linux client.xxx.com 2.6.33.5-112.fc13.i686
                              #1 SMP Thu May 27 03:11:56 UTC 2010 i686 i686
Alert Count                   20
First Seen                    Mon May 31 18:46:41 2010
Last Seen                     Tue Jun  1 10:43:59 2010
Local ID                      57c37d5e-73e9-4b85-a950-6a2f262ca79b
Line Numbers                  

Raw Audit Messages            

node=client.xxx.com type=AVC msg=audit(1275381839.206:75): avc:  denied  { getattr } for  pid=1218 comm="rpc.gssd" path="/tmp/krb5cc_10000_qyVeTx2978" dev=dm-0 ino=228504 scontext=system_u:system_r:gssd_t:s0 tcontext=system_u:object_r:sshd_tmp_t:s0 tclass=file

node=client.xxx.com type=SYSCALL msg=audit(1275381839.206:75): arch=40000003 syscall=196 success=no exit=-13 a0=bfcac9fc a1=bfcac4c8 a2=297ff4 a3=0 items=0 ppid=1 pid=1218 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="rpc.gssd" exe="/usr/sbin/rpc.gssd" subj=system_u:system_r:gssd_t:s0 key=(null)


# semanage boolean -l|grep gss
allow_gssd_read_tmp            -> on    Allow gssd to read temp directory.  For access to kerberos tgt.

$ ls -ldZ /tmp/krb5cc_10000_*
-rw-------. t.sailer users unconfined_u:object_r:user_tmp_t:s0 /tmp/krb5cc_10000_2qJQyi
-rw-------. t.sailer users system_u:object_r:sshd_tmp_t:s0  /tmp/krb5cc_10000_diAWVQ3203

There are two credentials cache. The first was created using kinit, the second by sshd (normally one would only have the second)
Comment 1 Daniel Walsh 2010-06-01 16:28:17 EDT
Miroslav, I have changed sshd to use user_tmp_t for its /tmp content.  I am pushing this out to Rawhide.  I think we should wait a little while to make sure this works.  If it does we can back port it to F13.

Thomas if you can build custom policy for now, until we are sure this change will not break anything else.
Comment 2 Thomas Sailer 2010-06-01 22:34:12 EDT
Thanks for taking a look at it. Will work around for now...
Comment 3 Miroslav Grepl 2010-11-02 12:37:49 EDT
Fixed in selinux-policy-3.7.19-70.fc13
Comment 4 Bug Zapper 2011-06-02 08:31:52 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Bug Zapper 2011-06-27 13:14:15 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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