Hide Forgot
Description of problem: Summary: SELinux is preventing sshd (sshd_t) "link" to <Unknown> (xdm_t). Detailed Description: [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] SELinux denied access requested by sshd. It is not expected that this access is required by sshd 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://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:sshd_t:SystemLow-SystemHigh Target Context system_u:system_r:xdm_t:SystemLow-SystemHigh Target Objects None [ key ] Source sshd Source Path /usr/sbin/sshd Port <Unknown> Host hubmaier.ceplovi.cz Source RPM Packages openssh-server-4.7p1-7.fc9 Target RPM Packages Policy RPM selinux-policy-3.2.6-2.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name catchall Host Name hubmaier.ceplovi.cz Platform Linux hubmaier.ceplovi.cz 2.6.24-9.fc9 #1 SMP Tue Jan 29 17:45:59 EST 2008 x86_64 x86_64 Alert Count 3 First Seen Po 4. únor 2008, 15:46:47 CET Last Seen Po 4. únor 2008, 16:53:24 CET Local ID 2a8f914b-a7a4-4d9f-8845-fe7d83eb42d2 Line Numbers Raw Audit Messages host=hubmaier.ceplovi.cz type=AVC msg=audit(1202140404.395:136): avc: denied { link } for pid=4862 comm="sshd" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=key host=hubmaier.ceplovi.cz type=SYSCALL msg=audit(1202140404.395:136): arch=c000003e syscall=250 success=yes exit=0 a0=8 a1=fffffffc a2=fffffffd a3=7fff21776740 items=0 ppid=2356 pid=4862 auid=4294967295 uid=500 gid=500 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) Version-Release number of selected component (if applicable): openssh-4.7p1-7.fc9.x86_64 selinux-policy-targeted-3.2.6-2.fc9.noarch
Created attachment 293990 [details] Just to complete my today's binge bug filling with /var/log/audit/audit.log
Just to note to the comment 0 -- I have now enforcing mode now, and the result is the same, but I sitll can use ssh connection even with these AVC denials.
Maybe the key got leaked through the restart of sshd in terminal in X? Could you try to restart sshd on text console and then try to connect again from another computer? The question is what should drop the key - su perhaps? Dan, do you have any idea how to fix that?
No, this computer was restarted completely couple of times, and I have never restarted sshd in X -- always just service ssh start during the boot of the system.
This is a bug in pam_keyinit and pam_selinux interaction. Tomas has the pam keycreatecon fix been released yet?
It was, but sshd doesn't call pam_selinux anyway. And it should call setkeycreatecon itself before PAM session is called.
Well that does not make sense, since the key was created with the xdm_t label so gdm created the original keyring. Matel, Did you how did you create this AVC? Is this just a normal Level 5 login and it happens? Or are you running at Run Level 3 and startx?
Sorry s/Matel/Matej
(In reply to comment #7) > Well that does not make sense, since the key was created with the xdm_t label so > gdm created the original keyring. > > Matel, Did you how did you create this AVC? Is this just a normal Level 5 login > and it happens? Or are you running at Run Level 3 and startx? > That's what confuses me too because a session spawned from a sshd should not have any access to a keyring created in xdm.
(In reply to comment #7) > Matel, Did you how did you create this AVC? Is this just a normal Level 5 login > and it happens? Or are you running at Run Level 3 and startx? This is very plain session 5, never touched /etc/init.d/sshd with chkconfig or anything else. I am from the desktop team, so I never cared that much about sshd and I hoped that it just works.
Strange is that suddenly when logging in from the console (which I don't usually) I got this as well: Summary: SELinux is preventing login (local_login_t) "search" to <Unknown> (xdm_t). Detailed Description: [SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.] SELinux denied access requested by login. It is not expected that this access is required by login 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://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:local_login_t:SystemLow- SystemHigh Target Context system_u:system_r:xdm_t:SystemLow-SystemHigh Target Objects None [ key ] Source login Source Path /bin/login Port <Unknown> Host hubmaier.ceplovi.cz Source RPM Packages util-linux-ng-2.13.1-3.fc9 Target RPM Packages Policy RPM selinux-policy-3.2.6-5.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name catchall Host Name hubmaier.ceplovi.cz Platform Linux hubmaier.ceplovi.cz 2.6.24-17.fc9 #1 SMP Mon Feb 4 18:35:53 EST 2008 x86_64 x86_64 Alert Count 2 First Seen St 6. únor 2008, 18:20:58 CET Last Seen St 6. únor 2008, 18:21:11 CET Local ID 872e307e-4de3-41a1-85d4-a002d11ee402 Line Numbers Raw Audit Messages host=hubmaier.ceplovi.cz type=AVC msg=audit(1202318471.760:169): avc: denied { search } for pid=2810 comm="login" scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=key host=hubmaier.ceplovi.cz type=SYSCALL msg=audit(1202318471.760:169): arch=c000003e syscall=250 success=yes exit=0 a0=3 a1=12231022 a2=ffffffffffffffff a3=1f4 items=0 ppid=1 pid=2810 auid=500 uid=0 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="login" exe="/bin/login" subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 key=(null)
Yes, that looks like gdm or pam_keyinit is not labelling the user keyring correctly. This is definitely not an openssh problem then.
I have a theory. Did you do a yum upgrade on this machine after logging in via gdm? gdm would have created a xdm_t keyring and then the yum update restarted both sshd and getty, causing those apps to look at xdm_t keyring. The latest pam fixes the mislabeled keyring, and I believe this problem will go away on reboot.
I was testing this with tmraz on IRC, and even after couple of reboots, the problem hasn't go away, but it seems to me that tmraz has some theory about what's going on (I think Tomáš was saying something about PAM doesn't relabel properly after gdm), but I will let him tell his story.
But yes, I was doing upgrade couple of times from withing gnome-session (via PackageKit, pup, or with yum upgrade in gnome-terminal).
Tomas, could you add your theory?
As gdm calls SELinux on its own probably the rawhide version either - doesn't call setkeycreatecon at all - calls it with a wrong context (not the default for the user) - calls it later than calling the pam_open_session() - calls it from a different child process than pam_open_session()
the gdm in rawhide actually doesn't call selinux apis at all. It relies soley on pam_selinux_permit/pam_selinux/pam_keyinit The gdm in F-8 and earlier *did* have some gdm specific selinux code. It's possible we'll need to add some I guess. I'll have to look at the F-8 patch and see if the changes are still applicable with the new code.
So here is my idea how this problem happens. I am not 100% sure that it is the case but it seems most probable. The gdm started calling pam_open_session() after it already did setreuid(<user>,...). This causes kernel to create the user keyring with the context xdm_t, because the setkeycreatecon(unconfined_t) was not yet called. The question is whether this can/should be somehow compensated for in pam_keyinit or whether the only way how to fix it is to not to do the setreuid in gdm before pam_open_session is called. David Howells - as you're the original author of pam_keyinit, what do you think about it?
As long as pam_keyinit is called after pam_selinux_open the keyring should be labeled unconfined_t (xguest_t, user_t, ...) So I think this is just a pam config problem. I investigated further on su and sudo handling of the keyring, and they were creating new keyrings since SELinux was not allowing them to see the current keyrings. pam_keyinit will create a new keyring if it does not have access to the current keyring. So we ended up having sudo_t and su_t keyrings. This has been fixed. Locallogin_t or sshd_t trying to access xdm_t keyring would only happen if xdm_t did not call pam_keyring after pam_selinux and then the user su or sudo to root and restarted the sshd or getty services. I actually believe this is all working correct in the current policy/pam configs so I am closing this as fixed in Rawhide Although we really need a way to examine the context on the keyring.
Dan, no, it doesn't work with current gdm in rawhide. The user keyring is created before the setkeycreatecon() from pam_selinux and thus it has xdm_t. The session keyring has correct unconfined_t but that is not the problem here.
I have a patch to provide a keyctl() function to retrieve the context on a key, and I have changes for the keyctl program to make use of it. Though the former isn't upstream yet, it's queued with Andrew to go in in the next merge window. It doesn't affect anything else, so it could be included in the kernel RPM until it goes upstream.
It sounds like I need to make the user keyrings and user session keyrings created only when they're actually asked for - either that or get rid of them completely (they're Linus mandated, so I may not be able to go that far, plus it'd potentially affect the operation of userspace). The problem is that calling setuid() or setreuid() or setresuid() to change the UID may[*] create the user keyrings for that user at that point. Similarly, executing a SUID binary may do so too. [*] ie: if not yet in existence for that user.
So the comment I have above that setreuid call is: /* pam_setcred wants to be called as the authenticated user * but pam_open_session needs to be called as super-user. * * Set the real uid and gid to the user and give the user a * temporary super-user effective id. */ I wrote that comment and the setreuid call because the pam_setcred man page says: However, it has been decided that [the user's UID and GID] are credentials that should be set directly [...] prior to a call to this function [pam_setcred] So, I think we need the setreuid call. I'm open to removing the call if it turns out the man page is wrong or I'm wrong. Independent of that, as David pointed out, I think that the kernel implicitly creating a keyring from a setreuid() call is wrong. Moving to kernel and changing summary.
Created attachment 297955 [details] Just-in-time user keyring creation This kernel patch will alleviate the problem with user keyrings being created with the wrong label by virtue of not creating them when the UID becomes known to the kernel, but rather when pam_keyinit calls for them. pam_keyinit can then be shuffled down the sequence till it's after pam_selinux. However, it won't fix sshd as that does its own SELinux thing after PAM has been played out, meaning that pam_keyinit is not called at a time when the process's security label is correct.
Thanks David. GDM should already be set to go. It currently does pam_keyinit after pam_selinux.
What's the status of this bug? I'm getting a big confused in the comments, where do we stand for fixing it in Fedora 9?
(In reply to comment #25) > So the comment I have above that setreuid call is: > > /* pam_setcred wants to be called as the authenticated user > * but pam_open_session needs to be called as super-user. > * > * Set the real uid and gid to the user and give the user a > * temporary super-user effective id. > */ > > I wrote that comment and the setreuid call because the pam_setcred man page says: > > However, it has been decided that [the user's UID and GID] are > credentials that should be set directly [...] prior to a call to > this function [pam_setcred] > > So, I think we need the setreuid call. I'm open to removing the call if it > turns out the man page is wrong or I'm wrong. The question is where this comment in the manpage came from and whether other applications really do it this way. Personally I don't know if there is any application which does this this way. As the pam_setcred should be called before the pam_open_session (at least this is the prefered order for Linux-PAM, though Solaris PAM asks for the reversed order in their docs) and pam_open_session should be called as root (at least effective uid has to be 0) it seems to me that this part of the manpage is questionable.
The docs are odd, for sure, on that front. If they're wrong, we could probably change gdm. Kernel should get fixed regardless, and David already has a patch. David, and luck on getting the patch upstream / in our packages?
*** Bug 440540 has been marked as a duplicate of this bug. ***
Ping?
This is no longer a blocker since gdm doesn't perform the setreuid call in recent builds.
*** Bug 439714 has been marked as a duplicate of this bug. ***
Latest policy also dontaudits this.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. 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 '9'. 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 9'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 9 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
I do not know if this is still true. But will move it to F11.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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
I haven't seen it for a long time ... let's call it closed.