Bug 436747

Summary: Login succeded even when host not validated
Product: [Fedora] Fedora Reporter: W. Michael Petullo <mike>
Component: pam_krb5Assignee: Nalin Dahyabhai <nalin>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 14CC: christian.assfalg, dqarras
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-16 15:36:24 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
Patch to split validation of credentials into a suid helper application none

Description W. Michael Petullo 2008-03-10 04:13:38 EDT
Description of problem:
I have configured pam_krb5 to verify that the TGT obtained from the realm’s
servers has not been spoofed using the validate option. I have noticed that if
the keytab used by pam_krb5 does not exist, then pam_krb5 will not require a
server validation. I would expect that logins whould fail when the keytab does
not exist because the validation requirement is not met.

Version-Release number of selected component (if applicable):
pam_krb5-2.2.18-1.ppc

How reproducible:
Every time

Steps to Reproduce:
1. Configure pam_krb5 to validate by adding validate = true to pam's appdefaults
block in /etc/krb5.conf.
2. Remove the keytab used by pam_krb5 (i.e.: /etc/krb5.keytab).
3. Log in and observe /var/log/secure
  
Actual results:
Mar 10 12:41:04 imp su: pam_krb5[8069]: error reading keytab, not verifying TGT
Mar 10 12:41:04 imp su: pam_krb5[8069]: authentication succeeds for 'admin'
(admin@FLYN.ORG)

Expected results:
Authentication should fail because I have required validation and it failed.

Additional info:
Comment 1 Nalin Dahyabhai 2008-03-10 17:51:54 EDT
The module skips validation when it can't access the keytab for whatever reason,
mainly to keep things like screen lock applications which run unprivileged from
failing due to permissions problems.  I'm open to alternate ideas of how to keep
that case from breaking.
Comment 2 W. Michael Petullo 2008-03-15 04:10:48 EDT
Does that mean one can spoof a Kerberos server when a user authenticates himself
for the screensaver regardless of the validation setting?

Using a SUID helper application can solve the keytab permissions problem. Both
pam_unix and pam_ccreds use this technique (I implemented it for pam_ccreds
using pam_unix as a model).

The only problem I see right now is that Kerberos crendentials are a little more
sophisticated than normal Unix passwords. In order to do this cleanly, I need to
find a way to pass the Kerberos credential between processes. Is there an
existing function to "pickle" the credentials struct into a string so I may pass
it to another process using a pipe?
Comment 3 Nalin Dahyabhai 2008-03-17 11:17:15 EDT
There isn't one.  The closest we get is storing the creds in a temporary
file-based credential cache and then reading the file's contents.  I'm not too
keen on passing random binary data to a setuid app, but I guess if that turns
up problems we need to fix them anyway.
Comment 4 W. Michael Petullo 2008-03-17 16:06:57 EDT
Created attachment 298301 [details]
Patch to split validation of credentials into a suid helper application

This is my first attempt at a patch to split the validation of credentials into
a suid helper application. This will allow applications running as normal users
to validate credentials even when the keytab is only readable by root.

Basically, the patch uses pam_krb5's existing shared memory capabilities to
share credentials with the helper. I had to modify some of the related
functions to make them usable from an exec'ed program.

There are some remaining issues with the patch:

o it requires the use_shmem pam_krb5 option
o the helper application needs to do a better job of logging
o _pam_krb5_blob_from_shm no longer checks to ensure that the shmem has the
same owner as the process
o some of it's not pretty -- I hope to clean it up once the concept is
developed

I'd like to solicit comments on the work done so far.
Comment 5 Bug Zapper 2008-11-26 05:06:03 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  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 '8'.

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 8'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 8 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 6 Christian Aßfalg 2008-11-26 05:33:33 EST
I am guessing that nothing has changed here, and this module is more or less the same in all current RedHat Flavours, including RHEL4+?

Since I do not have a good suggestion as to how to deal with this issue, I suggest to at least document this behaviour in the according man pages. I would have expected the same behaviour as the submitter. I remember having spent at least a couple of hours on testing and searching as to why the login did succeed when there was no keytab, and how to make it fail. The documentation is quite clear that the login shold fail yet it still does not.

The current implementation is not intuitive (even though it makes perfect sense), so it should be documented to avoid confusion.
Comment 7 Bug Zapper 2009-11-16 03:02:36 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 8 Bug Zapper 2010-11-04 08:01:01 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 9 W. Michael Petullo 2010-11-04 12:01:13 EDT
As far as I know, this bug still exists in Fedora 14. Bumping report to 14 because of the end of suppot for Fedora 12.
Comment 10 Fedora End Of Life 2012-08-16 15:36:28 EDT
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

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