Bug 142347 - SELinux passwd gives 'passwd: Authentication failure'
SELinux passwd gives 'passwd: Authentication failure'
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
3
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-09 00:25 EST by Durka Durka
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-31 11:02:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Durka Durka 2004-12-09 00:25:00 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:
Tried to disable SELinux, but once I finally did, the problem still
remains.  Denies me whenever 'passwd' is executed.  The lockfile in
/etc/.pwd.lock wont go away.
---
[root@localhost ~]# adduser pumpkin
[root@localhost ~]# passwd pumpkin
Changing password for user pumpkin.
New UNIX password:
Retype new UNIX password:
passwd: Authentication failure
---
very perplexing

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Type 'passwd'
2. put in the new passwords
3. Profit! <enter>
    

Actual Results:  passwd: Authentication failure

Expected Results:  changed the password

Additional info:

SELinux seems pretty horrible, i wish the installer had told me the
kind of troulbes it would cause for me.
Comment 1 Daniel Walsh 2004-12-09 09:59:35 EST
Are you seeing AVC messages?  Was this a fresh install or an upgrade?
Comment 2 Peter J. Dohm 2004-12-18 13:18:14 EST
i am experiencing identically the same behavior.
it was a fresh install, and i get NO AVC messages whatsoever...

selinux is in "permissive" mode.

i'm thinking this is more likely related to pam than to selinux
directly.  were there altered pam directives put in place when selinux
gets installed, or something similar to that?
Comment 3 Daniel Walsh 2004-12-19 06:57:47 EST
Are you running with targeted or strict policy.  In permissive mode or
targeted policy the passwd command runs in a unconfined mode. so there
really should be no difference.

What type of authentication are you using?

Dan
Comment 4 Paul Eden 2004-12-22 18:42:12 EST
I have the same issue.

Mine install of FC3 was an upgrade from FC2.

I am using:
SELINUX=enforcing
SELINUXTYPE=targeted
in /etc/sysconfig/selinux

Im am using MD5 Passwords and shadow passwords and PAM (all the
defaults) no ldap, nis, etc for authentication.

Comment 5 Daniel Walsh 2005-01-05 08:44:18 EST
Did you relabel after the upgrade?
Comment 6 Paul Eden 2005-01-05 10:38:34 EST
No, I do not know what that is.
Comment 7 Daniel Walsh 2005-01-05 10:50:06 EST
touch /.autorelabel
reboot
If you turn on selinux you need to relabel your file system.  In the
SELinux world, all files have a label associated with them.  You can
do a ls -Z to see the labels.  The labels (or contexts) are used to
make Access control decisions.  If you upgraded most of your labels
are wrong.

http://fedora.redhat.com/docs/selinux-faq-fc3/
Comment 8 Paul Eden 2005-01-06 12:31:17 EST
That worked on one machine I upgraded to fc3, but not on another.  

Both machines are set to:
SELINUX=enforcing
SELINUXTYPE=targeted
in /etc/sysconfig/selinux

I have not yet read the selinux faq, so I suspect the reason for the
2nd machine not yet working with selinux is answered there.
Comment 9 John Robinson 2005-01-28 18:44:24 EST
This had me going for a while, not being able to set a password for my
own personal (non-root) user account.

Here's what I found (commands and output as shown):

[root@out ~]# passwd john
Changing password for user john.
New UNIX password:
Retype new UNIX password:
passwd: Authentication failure
[root@out ~]# ls -Zl /etc/shadow*
-r--------  1                                  root root 1288 Jan 28
23:25 /etc/shadow
-rw-------  1 system_u:object_r:shadow_t       root root 1288 Jan 28
23:23 /etc/shadow-
[root@out ~]# restorecon /etc/shadow
[root@out ~]# passwd john
Changing password for user john.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
[root@out ~]# passwd john
Changing password for user john.
New UNIX password:
Retype new UNIX password:
passwd: Authentication failure
[root@out ~]#

So, something (passwd? pam?) is losing the context on /etc/shadow with
the effect that only one person can change one password until someone
does a restorecon. I've a new FC3 installation (not upgrade),
reasonably up2date (it was yesterday), passwd 0.68-10, pam 0.77-66.2.

I think SELinux is supposed to be being permissive (well that's what I
put in /etc/selinux/config) with the targeted policy, but the above
behaviour makes me think it must be enforcing. That's not the point
here though; passwd (or whatever) breaking the security context is the
point.
Comment 10 John Robinson 2005-01-29 06:26:28 EST
Oh, if it makes any difference, my root filesystem uses ReiserFS over lvm.
Comment 11 Daniel Walsh 2005-01-31 11:02:41 EST
ReiserFS is not supported with SELinux by FC3.  I believe there are
problems with the Reiser File system and exteneded attributes. 
Contact the SELinux@tycho.nsa.gov mailing list if you need help.  

Dan
Comment 12 John Robinson 2005-01-31 14:52:51 EST
You shouldn't have closed this; I may be using ReiserFS but the
original reporter didn't say that. Also, I may be using ReiserFS but
it looks like it's is supporting extended attributes correctly in this
instance. It sounds as if you may have been a little quick to judge;
please look again. Durka, please comment.
Comment 13 Daniel Walsh 2005-01-31 15:06:35 EST
Sorry we have a hole bunch of these with the same symptoms and so far
everyone is reiserfs.  Which we don't test or support.
If Durka states otherwise I will take a look at it.

Dan
Comment 14 Owen LaGarde 2005-04-20 16:05:10 EDT
I'm getting the same behavior with ext3 on a kitchen-sink FC3 install.  To
reproduce:

-  new FC3 install, add "everything".
-  set the root password on install
-  reboot, complete install, yadda yadda yadda
-  update all rpms (kernel included) as of 7 April 2005, rhn/sources =
    yum fedora-core-3
       http://download.fedora.redhat.com/pub/fedora/linux/core/3/$ARCH/os/)
    yum updates-released-fc3
       http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/$ARCH/
-  attempt to set new root password with "passwd":
    # passwd
    Changing password for user root.
    New UNIX password:
    Retype new UNIX password:
    passwd: Authentication failure
    #

I may be wrong on this but I think the default SELinux and PAM policies require
labels on *both* /etc/passwd and /etc/shadow, but...

    # restorecon -o /tmp/fubar -n /etc/shadow
    # cat /tmp/fubar
    /etc/shadow
    # restorecon -o /tmp/fubar -n /etc/passwd
    # cat /tmp/fubar
    # ls -lZ /etc/passwd
    -rw-r--r--  root     root     system_u:object_r:etc_t          /etc/passwd
    # ls -lZ /etc/shadow
    -r--------  root     root                                      /etc/shadow
    #

Any other data I should gather before running fixfiles/restorecon?
Comment 15 Daniel Walsh 2005-04-20 16:18:17 EDT
/etc/shadow has no context on it?

    # restorecon -o /tmp/fubar -n /etc/shadow
    # cat /tmp/fubar
    /etc/shadow
    # restorecon -o /tmp/fubar -n /etc/passwd
    # cat /tmp/fubar

I think you need a -v qualifier to do what you expect.

/etc/passwd should be etc_t but shadow should be shadow_t

rhn might be the problem here.  If that is not running in rpm context, or some
app rewrote the /etc/shadow from a file system that does not support file context.



Comment 16 Owen LaGarde 2005-04-20 16:22:34 EDT
A 'restorecon' worked just fine on clone of the problem system's physical
volumes.  I have a hunch that the core problem was a failed auto-label on first
boot after the install;  spot checking output from 'fixfiles -R -a' in 'check'
mode on the clone system looks like there were no labels on any package members
written during/after the base PAM install.  Me, I'm blaming planetary alignment.
Comment 17 Owen LaGarde 2005-04-20 16:26:04 EDT
Na, that's habit.  I wanted file output rather than stdout.  I don't think the
problem is rhn -- it was used to update packages which have member correctly
labeled.  This looks more like a one-time failure to me.


(In reply to comment #15)
> /etc/shadow has no context on it?
> 
>     # restorecon -o /tmp/fubar -n /etc/shadow
>     # cat /tmp/fubar
>     /etc/shadow
>     # restorecon -o /tmp/fubar -n /etc/passwd
>     # cat /tmp/fubar
> 
> I think you need a -v qualifier to do what you expect.
> 
> /etc/passwd should be etc_t but shadow should be shadow_t
> 
> rhn might be the problem here.  If that is not running in rpm context, or some
> app rewrote the /etc/shadow from a file system that does not support file context.
> 
> 
> 
> 

Comment 18 Owen LaGarde 2005-04-20 17:01:07 EDT
Odd.  Testing rhn/up2date involvement for package mc, which happens to be in the
previous test output and have an update available:

- 'fixfiles -R mc check' reported resets required for

   /usr/share/mc/bin
   /usr/share/mc/bin/mc-wrapper.csh
   /usr/share/mc/bin/mc.sh
   /usr/share/mc/bin/mc.csh
   /usr/share/mc/bin/mc-wrapper.sh

- 'up2date -u mc' updated mc to mc-4.6.1-0.13.FC3
- 'fixfiles -R mc check' now reports no problems
Comment 19 Owen LaGarde 2005-04-20 17:21:50 EDT
I was backward in my earlier statement that the problem was limited to a subset
of RPM installs after PAM ... it's the packages that have been *updated* that
*do* have correct EAs.  RHN and up2date have been populating missing EAs on top
of what appears to be an install sans any labels.  If I recall, there was a
pre-release FC3 bug that caused system-config-securitylevel to not create
.autorelabel;  the install media is not test release, but the dates are 3 Nov
2004 and the bug was still being reported mid-Nov.  If the bug made it into the
first cut of major release, that would explain all of the above.  I'll pull a
fresh copy of the dist and repeat the test, but I think we have a culprit;  the
auto-label was never performed at firstboot.

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