Bug 801163
| Summary: | SELinux prevents chsh from working with Kerberos auth | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Ben Webb <benmwebb> |
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED ERRATA | QA Contact: | Zbysek MRAZ <zmraz> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.2 | CC: | dwalsh, ebenes, mmalik, nalin, ssorce |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | selinux-policy-3.7.19-151.el6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-06-20 12:31:57 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Why would chfn be creating a host_0 file? Well it looks like we have this in Fedora. Might want to start back porting the auth_use_pam interface. (In reply to comment #2) > Why would chfn be creating a host_0 file? It uses PAM, and it's running with sufficient privileges that when pam_krb5 calls the verify-creds APIs, it can read the system keytab and attempt to use it to verify the initial credentials, which currently involves creating/using the replay cache. We are missing auth_use_pam(chfn_t) Fixed in selinux-policy-3.7.19-151.el6 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0780.html |
Description of problem: 'chsh' does not work on our servers that authenticate with Kerberos; SELinux prevents it from accessing certain files and directories. (If SELinux is set to permissive mode, chsh works correctly.) Version-Release number of selected component (if applicable): selinux-policy-targeted-3.7.19-126.el6_2.9.noarch util-linux-ng-2.17.2-12.4.el6.x86_64 How reproducible: Always. Steps to Reproduce: 1. On a system using Kerberos authentication, attempt to change the shell: $ chsh -s /bin/tcsh Actual results: Even if the correct password is entered at the prompt, chsh replies with: Authentication failure The following avcs are also seen in the log: Mar 7 11:45:53 server kernel: type=1400 audit(1331149553.094:35): avc: denied { read write } for pid=19772 comm="chsh" name="host_0" dev=cciss!c0d0p1 ino=139884 scontext=unconfined_u:unconfined_r:chfn_t:s0-s0:c0.c1023 tcontext=system_u:object_r:krb5_host_rcache_t:s0 tclass=file Mar 7 11:45:53 server kernel: type=1400 audit(1331149553.181:36): avc: denied { write } for pid=19772 comm="chsh" name="tmp" dev=cciss!c0d0p1 ino=128030 scontext=unconfined_u:unconfined_r:chfn_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=dir Expected results: Shell successfully changed. Additional info: If we put SELinux into permissive mode, chsh succeeds, albeit with a lot more avcs. audit2allow generates the following policy rules from those avcs: allow chfn_t krb5_host_rcache_t:file { rename write read create unlink open }; allow chfn_t tmp_t:dir { write remove_name add_name };