Bug 431535 - kernel shouldn't implicitly create user keyring after setreuid call.
kernel shouldn't implicitly create user keyring after setreuid call.
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
All Linux
low Severity low
: ---
: ---
Assigned To: David Howells
Fedora Extras Quality Assurance
: Reopened, SELinux, Triaged
: 439714 440540 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-05 06:28 EST by Matěj Cepl
Modified: 2013-01-09 23:33 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-04 09:13:05 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)
Just-in-time user keyring creation (15.21 KB, patch)
2008-03-13 12:40 EDT, David Howells
no flags Details | Diff

  None (edit)
Description Matěj Cepl 2008-02-05 06:28:30 EST
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
Comment 1 Matěj Cepl 2008-02-05 06:28:31 EST
Created attachment 293990 [details]
Just to complete my today's binge bug filling with /var/log/audit/audit.log
Comment 2 Matěj Cepl 2008-02-05 06:30:01 EST
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.
Comment 3 Tomas Mraz 2008-02-05 06:44:21 EST
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?
Comment 4 Matěj Cepl 2008-02-05 06:46:56 EST
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.
Comment 5 Daniel Walsh 2008-02-05 15:14:31 EST
This is a bug in pam_keyinit and pam_selinux interaction.  

Tomas has the pam keycreatecon fix been released yet?

Comment 6 Tomas Mraz 2008-02-05 17:37:12 EST
It was, but sshd doesn't call pam_selinux anyway. And it should call
setkeycreatecon itself before PAM session is called.
Comment 7 Daniel Walsh 2008-02-06 08:51:02 EST
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?
Comment 8 Daniel Walsh 2008-02-06 08:52:07 EST
Sorry s/Matel/Matej
Comment 9 Tomas Mraz 2008-02-06 08:58:56 EST
(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.
Comment 10 Matěj Cepl 2008-02-06 10:15:13 EST
(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.
Comment 12 Matěj Cepl 2008-02-06 12:24:38 EST
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)


Comment 13 Tomas Mraz 2008-02-06 12:33:33 EST
Yes, that looks like gdm or pam_keyinit is not labelling the user keyring
correctly. This is definitely not an openssh problem then.
Comment 14 Daniel Walsh 2008-02-06 15:54:49 EST
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.
Comment 15 Matěj Cepl 2008-02-06 16:32:41 EST
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.
Comment 16 Matěj Cepl 2008-02-06 16:33:21 EST
But yes, I was doing upgrade couple of times from withing gnome-session (via
PackageKit, pup, or with yum upgrade in gnome-terminal).
Comment 17 Matěj Cepl 2008-02-14 10:14:42 EST
Tomas, could you add your theory?
Comment 18 Tomas Mraz 2008-02-15 06:08:19 EST
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()
Comment 19 Ray Strode [halfline] 2008-02-15 09:20:40 EST
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.
Comment 20 Tomas Mraz 2008-03-06 10:31:33 EST
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?
Comment 21 Daniel Walsh 2008-03-06 11:29:10 EST
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.


Comment 22 Tomas Mraz 2008-03-06 11:37:49 EST
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.
Comment 23 David Howells 2008-03-06 11:44:26 EST
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.
Comment 24 David Howells 2008-03-06 11:48:52 EST
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.
Comment 25 Ray Strode [halfline] 2008-03-06 13:11:18 EST
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.
Comment 26 David Howells 2008-03-13 12:40:53 EDT
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.
Comment 27 Ray Strode [halfline] 2008-03-13 13:18:04 EDT
Thanks David.

GDM should already be set to go.  It currently does pam_keyinit after pam_selinux.
Comment 28 Jesse Keating 2008-04-01 17:15:42 EDT
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?
Comment 29 Tomas Mraz 2008-04-02 07:57:40 EDT
(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.
Comment 30 Ray Strode [halfline] 2008-04-02 13:48:16 EDT
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?
Comment 31 Daniel Walsh 2008-04-04 17:03:37 EDT
*** Bug 440540 has been marked as a duplicate of this bug. ***
Comment 32 Jesse Keating 2008-04-08 23:00:10 EDT
Ping?
Comment 35 Ray Strode [halfline] 2008-04-11 23:59:21 EDT
This is no longer a blocker since gdm doesn't perform the setreuid call  in
recent builds.
Comment 37 Dave Jones 2008-04-14 12:49:30 EDT
*** Bug 439714 has been marked as a duplicate of this bug. ***
Comment 38 Daniel Walsh 2008-04-14 13:28:37 EDT
Latest policy also dontaudits this.
Comment 39 Bug Zapper 2008-05-14 01:00:18 EDT
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
Comment 40 Bug Zapper 2009-06-09 19:29:47 EDT
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
Comment 41 Daniel Walsh 2009-06-10 06:18:54 EDT
I do not know if this is still true.  But will move it to F11.
Comment 42 Bug Zapper 2009-11-16 03:01:01 EST
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
Comment 43 Bug Zapper 2010-11-04 08:02:55 EDT
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
Comment 44 Matěj Cepl 2010-11-04 09:13:05 EDT
I haven't seen it for a long time ... let's call it closed.

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