Description of problem: Kinit fails to save the kerberos ticket for confined user. Version-Release number of selected component (if applicable): How reproducible: Okay, I narrowed down the problem, it happens because of confining of users using selinux Steps to reproduce is: 1. Install F-20 2. create user testuser using useradd 3. Confine user using semanage $semanage login -a -s user_u testuser 4. Login as testuser 5. Run knit Creating custom module using below "te" file works module mykinit 1.0; require { type staff_t; type ssh_t; class key { write view }; } #============= staff_t ============== allow staff_t ssh_t:key { write view }; Actual results: kinit fails Expected results: kinit should be successful for confined user. Additional info:
Additional Information: SELinux is preventing /usr/bin/kinit from 'write' accesses on the key . ***** Plugin catchall (100. confidence) suggests ************************** If you believe that kinit should be allowed write access on the key by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep kinit /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context staff_u:staff_r:staff_t:s0-s0:c0.c1023 Target Context staff_u:staff_r:ssh_t:s0-s0:c0.c1023 Target Objects [ key ] Source kinit Source Path /usr/bin/kinit Port <Unknown> Host (removed) Source RPM Packages krb5-workstation-1.11.3-33.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-106.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.12.5-302.fc20.x86_64 #1 SMP Tue Dec 17 20:42:32 UTC 2013 x86_64 x86_64 Alert Count 1 First Seen 2013-12-27 15:41:49 IST Last Seen 2013-12-27 15:41:49 IST Local ID 388183bd-95f3-4fad-95ad-2de092258c76 Raw Audit Messages type=AVC msg=audit(1388139109.621:776): avc: denied { write } for pid=6032 comm="kinit" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:ssh_t:s0-s0:c0.c1023 tclass=key type=SYSCALL msg=audit(1388139109.621:776): arch=x86_64 syscall=add_key success=no exit=EACCES a0=7fc215492a86 a1=7fc216feea60 a2=0 a3=0 items=0 ppid=5822 pid=6032 auid=1004 uid=1004 gid=1005 euid=1004 suid=1004 fsuid=1004 egid=1005 sgid=1005 fsgid=1005 ses=1 tty=pts2 comm=kinit exe=/usr/bin/kinit subj=staff_u:staff_r:staff_t:s0-s0:c0.c1023 key=(null) Hash: kinit,staff_t,ssh_t,key,write
Ok this looks like the kernel keyring for some reason was created with the context of ssh_t? Instead of staff_t. Did you run ssh before trying to execute kinit?
I figure you must have logged in and then tried to ssh to another box, which creates the keyring, when the ssh failed because you did not have kerberos tix, you ran kinit, and staff_t is not allowed to write to ssh_t key. This seems to be a potential problem since we would not know which process type created the keyring.
No i did not run ssh to login to remote box, I am just trying to login locally on my system and trying to run kinit
Well then I am truly confused onto why there would be a ssh_t:key?
The keyring appears to be labelled in accordance with the label of the process that caused it to be created.
(In reply to Nalin Dahyabhai from comment #6) > The keyring appears to be labelled in accordance with the label of the > process that caused it to be created. This is not good. Any chance to change it to something static and reasonable?
I think we need to know what the destination keyring ID is in the failing add_key() syscall. Unfortunately, it appears the audit log doesn't log it (it would be a4=). Can you strace the kinit program to find the keyrings syscalls it is doing: strace -eadd_key,keyctl kinit Amongst the syscalls output, there should be some add_key() calls, eg: add_key(0x7f4493066ab0, 0x7f4493066ad0, 0x7f449513ec90, 0x22, 0x3549ada6) = 876551079 add_key(0x7f4493066ab0, 0x7f4493066ae8, 0x7f449513ed50, 0x8, 0x3549ada6) = 279376607 add_key(0x7f4493066afe, 0x7f449513ec90, 0x7f449513f2c0, 0x1b0, 0x3549ada6) = 324125037 The last argument is the destination keyring ID (in this case 0x3549ada6). Can you then do: keyctl desc <keyring-ID> keyctl security <keyring-ID> eg: warthog>keyctl desc 0x3549ada6 894021030: alswrv-----v------------ 4043 4043 keyring: 4043 warthog>keyctl security 0x3549ada6 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
I am unable to reproduce the issue again, After the initial selinux message, I created the selinux module to allow kinit to run. module mykinit 1.0; require { type staff_t; type ssh_t; class key { write view }; } #============= staff_t ============== allow staff_t ssh_t:key { write view }; I removed the module using semodule -r and tried to reload the module and reboot, but now i am able to run kinit properly and it doesn't throw any message. Not sure what got changed, I am running kinit as user "mniranja" who is mapped to staff_u [mniranja@mniranja ~]$ id -Z staff_u:staff_r:staff_t:s0-s0:c0.c1023 Below is snip of successful kinit strace. ) = 1 ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon -echo ...}) = 0 ioctl(3, SNDCTL_TMR_START or SNDRV_TIMER_IOCTL_TREAD or TCSETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f90a9756cd0}, NULL, 8) = 0 close(3) = 0 keyctl(0xa, 0xf1e4a23, 0x7f90aa9f8a86, 0x7f90ad348a60, 0) = -1 ENOKEY (Required key not available) add_key(0x7f90aa9f8a86, 0x7f90ad348a60, 0, 0, 0xf1e4a23) = 130968590 add_key(0x7f90aa9f8ab0, 0x7f90aa9f8ad0, 0x7f90ad3529b0, 0x22, 0x7ce6c0e) = 495880634 add_key(0x7f90aa9f8ab0, 0x7f90aa9f8ae8, 0x7f90ad352a70, 0x8, 0x7ce6c0e) = 1061870915 add_key(0x7f90aa9f8afe, 0x7f90ad3529b0, 0x7f90ad352fe0, 0x1b0, 0x7ce6c0e) = 801552045 keyctl(0xf, 0x2fc6b6ad, 0x8c9a, 0, 0x7ce6c0e) = 0 keyctl(0xb, 0x7ce6c0e, 0, 0, 0x7ce6c0e) = 12 keyctl(0xb, 0x7ce6c0e, 0x7f90ad352a70, 0xc, 0) = 12 keyctl(0xa, 0x7ce6c0e, 0x7f90aa9f8ab0, 0x7f90aa9f8ae8, 0) = 1061870915 keyctl(0xb, 0x2fc6b6ad, 0, 0, 0) = 432 keyctl(0xb, 0x2fc6b6ad, 0x7f90ad3531c0, 0x1b0, 0) = 432 keyctl(0xf, 0x7ce6c0e, 0x8c9a, 0, 0x1) = 0 munmap(0x7f90a273f000, 2109688) = 0 exit_group(0) = ? +++ exited with 0 +++ [mniranja@mniranja ~]$ keyctl desc 0x7ce6c0e 130968590: alswrv-----v------------ 1004 1005 keyring: 1004 [mniranja@mniranja ~]$ keyctl security 0x7ce6c0e staff_u:staff_r:staff_t:s0-s0:c0.c1023
So you added a new confined user using semanage and tried to log in using ssh and ran kinit without log out/in?
As far as i remember, i have not run kinit after logging in to a remote box, I will try a fresh fedora 20 and try reproduce the issue again.
Some How the issue got reproduced again, [mniranja@mniranja ~]$ strace -eadd_key,keyctl kinit keyctl(0x16, 0x3ec, 0xfffffffe, 0, 0x7f9d7f871060) = 200291142 keyctl(0xa, 0xbf03346, 0x7f9d8078fa66, 0x7f9d8078faa2, 0xfffffffe) = 394073912 keyctl(0xa, 0x177d1738, 0x7f9d8078fa90, 0x7f9d8078fae6, 0) = 323755689 keyctl(0xb, 0x134c1ea9, 0, 0, 0) = 13 keyctl(0xb, 0x134c1ea9, 0x7f9d828bb960, 0xd, 0) = 13 keyctl(0xa, 0x177d1738, 0x7f9d8078fa66, 0x7f9d828bb980, 0) = -1 ENOKEY (Required key not available) keyctl(0xa, 0, 0x7f9d8078fa90, 0x7f9d8078fab0, 0) = -1 EINVAL (Invalid argument) keyctl(0x16, 0x3ec, 0xfffffffe, 0, 0x7f9d7f871060) = 200291142 keyctl(0xa, 0xbf03346, 0x7f9d8078fa66, 0x7f9d8078faa2, 0xfffffffe) = 394073912 keyctl(0xa, 0x177d1738, 0x7f9d8078fa90, 0x7f9d8078fae6, 0) = 323755689 keyctl(0xb, 0x134c1ea9, 0, 0, 0) = 13 keyctl(0xb, 0x134c1ea9, 0x7f9d828bdb90, 0xd, 0) = 13 keyctl(0xb, 0x177d1738, 0, 0, 0x7f9d828bdb98) = 4 keyctl(0xb, 0x177d1738, 0x7f9d828bdb90, 0x4, 0) = 4 keyctl(0xa, 0x177d1738, 0x7f9d8078fa66, 0x7f9d828bdbb0, 0) = -1 ENOKEY (Required key not available) keyctl(0x6, 0x134c1ea9, 0, 0, 0) = -1 EACCES (Permission denied) Password for mniranja: keyctl(0xa, 0x177d1738, 0x7f9d8078fa66, 0x7f9d828bba60, 0) = -1 ENOKEY (Required key not available) add_key(0x7f9d8078fa66, 0x7f9d828bba60, 0, 0, 0x177d1738) = -1 EACCES (Permission denied) +++ exited with 0 +++ [mniranja@mniranja ~]$ keyctl security 0x177d1738 keyctl_getsecurity: Required key not available [mniranja@mniranja ~]$ keyctl desc 0x177d1738 keyctl_describe: Permission denied [mniranja@mniranja ~]$ id -Z staff_u:staff_r:staff_t:s0-s0:c0.c1023
Below is the AVC Message SELinux is preventing /usr/bin/kinit from view access on the key . ***** Plugin catchall (100. confidence) suggests ************************** If you believe that kinit should be allowed view access on the key by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep kinit /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context staff_u:staff_r:staff_t:s0-s0:c0.c1023 Target Context staff_u:staff_r:ssh_t:s0-s0:c0.c1023 Target Objects [ key ] Source kinit Source Path /usr/bin/kinit Port <Unknown> Host mniranja.pnq.redhat.com Source RPM Packages keyutils-1.5.8-1.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-119.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name mniranja.pnq.redhat.com Platform Linux mniranja.pnq.redhat.com 3.12.8-300.fc20.x86_64 #1 SMP Thu Jan 16 01:07:50 UTC 2014 x86_64 x86_64 Alert Count 9 First Seen 2014-02-06 11:58:31 IST Last Seen 2014-02-06 12:05:22 IST Local ID d5ad5bb5-58c3-435b-a6d8-c56da3927f34 Raw Audit Messages type=AVC msg=audit(1391668522.803:625): avc: denied { view } for pid=4413 comm="keyctl" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:ssh_t:s0-s0:c0.c1023 tclass=key type=SYSCALL msg=audit(1391668522.803:625): arch=x86_64 syscall=keyctl success=no exit=EACCES a0=6 a1=177d1738 a2=0 a3=0 items=0 ppid=3888 pid=4413 auid=1004 uid=1004 gid=1005 euid=1004 suid=1004 fsuid=1004 egid=1005 sgid=1005 fsgid=1005 ses=1 tty=pts5 comm=keyctl exe=/usr/bin/keyctl subj=staff_u:staff_r:staff_t:s0-s0:c0.c1023 key=(null) Hash: kinit,staff_t,ssh_t,key,view admin_server = FILE:/var/log/kadmind.log [libdefaults] dns_lookup_realm = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true rdns = false default_realm = REDHAT.COM default_ccache_name = KEYRING:persistent:%{uid} dns_lookup_kdc = false [realms] REDHAT.COM = { kdc = kerberos.corp.redhat.com admin_server = kerberos.corp.redhat.com } [domain_realm] .redhat.com = REDHAT.COM redhat.com = REDHAT.COM [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false }
Can anyone shed more information on what is target context and to what target context is ssh_t is getting set. ?
key view permission is checked to filter the results of reading /proc/keys based on whether the reading process security context (the source security context) is allowed view permission to the key security context (the target security context). Since the target is ssh_t, that means that the key was allocated while running in the ssh_t domain, e.g. as a result of an action by ssh (possibly in its pam stack or directly) without previously calling setkeycreatecon() to set the context to another.
This seems to happen if i do the following 1. configure local system /etc/krb5.conf to a kerberos realm 2. Open terminal and ssh to remote system (no kerberos is used to authenticate) 3. Some times open multiple tabs and logon to remote systems using ssh (Again no kerberos authentication is used ) 4. on the same terminal do kinit on local system to get kerberos ticket and it fails The above steps doesn't actually reproduce the problem everytime, it happens randomly.
e194215de82481660c25adb8715d007f3a59c05f allows this in git.
selinux-policy-3.12.1-126.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-126.fc20
Package selinux-policy-3.12.1-126.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-126.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-2801/selinux-policy-3.12.1-126.fc20 then log in and leave karma (feedback).
Package selinux-policy-3.12.1-127.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-127.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-2801/selinux-policy-3.12.1-127.fc20 then log in and leave karma (feedback).
selinux-policy-3.12.1-127.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.