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.