Bug 163092 - Targeted selinux policy breaks klogin
Targeted selinux policy breaks klogin
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-12 16:13 EDT by Danny Padwa
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: 1.25.4-10.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-15 11:58:29 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 Danny Padwa 2005-07-12 16:13:58 EDT
Description of problem:
Incoming klogin doesn't work under targeted selinux policy

Version-Release number of selected component (if applicable):
selinux-policy-targeted-1.25.1-7

How reproducible:
Extremely

Steps to Reproduce:
1. set up FC4 with selinux-policy-targeted
2. set up klogin (including getting a keytab)
3. try incoming klogin
  
Actual results:
Client cannot authenticate

Expected results:
Client should be able to authenticate

Additional info:
Interesting thing is that incoming kshell does work.   strace reveals that 
both processes do a
open( "/etc/krb5.keytab", O_RDONLY|O_LARGEFILE )
fcntl64( fd, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}, ptr )

The failing klogin gets an error from fcntl64 (and then barfs).  The happy ksh 
gets back a 0.   I can attach a full strace output if you want, or SELinux log 
messages, if you can tell me where to find them

The security context on /etc/krb5.keytab is system_u:object_r:krb5_conf_t

Setting SELinux to permissive makes incoming klogin work the way it should

Looks like klogin needs to be classified more like ksh for SELinux purposes
Comment 1 Danny Padwa 2005-07-12 16:18:57 EDT
Oops.  I realized that that security context was after I was playing with it.

restorecon resets the context to system_u:object_r:krb5_keytab_t, which 
results in exactly the same client breakage :-(
Comment 2 Danny Padwa 2005-07-12 16:38:17 EDT
Hunting deeper, I see that the error message looks like:

type=AVC msg=audit(1121199912.580:796215): avc:  denied  { read } for  
pid=3370 comm="klogind" name="krb5.keytab" dev=dm-0 ino=1737116 
scontext=system_u:system_r:rlogind_t tcontext=system_u:object_r:krb5_keytab_t 
tclass=file
type=SYSCALL msg=audit(1121199912.580:796215): arch=40000003 syscall=5 
success=no exit=-13 a0=8c786c0 a1=8000 a2=1b6 a3=8c7b998 items=1 pid=3370 
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
comm="klogind" exe="/usr/kerberos/sbin/klogind"
Comment 3 Daniel Walsh 2005-07-14 11:27:30 EDT
selinux-policy-targeted-1.25.2-4
Comment 4 Danny Padwa 2005-07-26 09:55:30 EDT
(In reply to comment #3)
> selinux-policy-targeted-1.25.2-4

Still broken in 1.25.3-5

:-(
Comment 5 Daniel Walsh 2005-07-26 14:36:37 EDT
Did you get different avc messages?
Comment 6 Danny Padwa 2005-07-26 14:57:22 EDT
Slightly different.   Looks like it is a lock rather than a read that is 
failing.

type=AVC msg=audit(1122403463.197:6409603): avc:  denied  { lock } for pid=6230
 comm="klogind" name="krb5.keytab" dev=dm-0 ino=1737116 
scontext=system_u:system_r:rlogind_t tcontext=system_u:object_r:krb5_keytab_t 
tclass=file
type=SYSCALL msg=audit(1122403463.197:6409603): arch=40000003 syscall=221 
success=no exit=-13 a0=7 a1=e a2=bf8c3cd4 a3=bf8c3cd4 items=0 pid=6230 
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
comm="klogind" exe="/usr/kerberos/sbin/klogind"
type=AVC_PATH msg=audit(1122403463.197:6409603):  path="/etc/krb5.keytab"

I made a one-line change to policy-20050719.patch from the 1.25.3-5 RPM and it 
now works....


padwad-fc4a$ diff policy-20050719.patch policy-20050726.patch
430c430
< +allow rlogind_t krb5_keytab_t:file { getattr read };
---
> +allow rlogind_t krb5_keytab_t:file { getattr read lock };

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