Bug 1018828

Technically the rules are implemented in the pam package (special-casing uid==0), but before reassigning - Stephen, why is this (long-standing) behavior a problem?

root is able to edit /etc/shadow directly, so prompting for a password in passwd(1) would not actually limit anything AFAICS.

There's no real protection against an attacker finding an unlocked session with a full shell in any case: for example, even if passwd(1) prompted for a password and /etc/shadow were somehow protected, the attacker could modify ~/.bash_* to capture all entered input and send it to the attacker, which would eventually also capture the required passwords.


Also consider recovery from forgotten root password - now the admin can boot into single-user mode, and use passwd(1) to reset the password; if passwd(1) were requiring the old password, the admin would have to manually delete the password field in /etc/shadow first, one extra non-trivial step.

Hmm, I could have sworn I remember being challenged to change the root password in older versions of Fedora, but it's possible my memory is faulty.

You make a good point about the shadow file. I suppose closing this hole wouldn't be a complete solution (although SELinux can be used to protect access to the file, even from root in some situations).

(In reply to Stephen Gallagher from comment #4)
> Hmm, I could have sworn I remember being challenged to change the root
> password in older versions of Fedora, but it's possible my memory is faulty.

I can't remember the root password being mandatory, but my memory isn't that great either.

> You make a good point about the shadow file. I suppose closing this hole
> wouldn't be a complete solution (although SELinux can be used to protect
> access to the file, even from root in some situations).

Right, and SELinux does protect the file: (on F19) only unconfined_t and cloud_init_t can both modify shadow_t directly and transition to passwd_t by executing /usr/bin/passwd.  However, guest_t, staff_t and sysadm_t can't access /etc/shadow directly, but they can transition to passwd_t, which allows passwd(1) to modify /etc/shadow.

Dan, how is are roles and protection of /etc/shadow against root supposed to work?  I remember a configuration in which an user is prompted to choose a role after login, however all roles used the same password; in that case the current situation is fine.

Can it happen that a "root" (UID=0) user in a confined role doesn't (and musn't) know root's password?

This is really RFE as it was always like that. I could imagine that in case the user is confined we could require entering old password. In other cases it really does not make sense.

If you are running as a confined user and as root, executing the passwd command will still require you to enter the root password.

The passwd tool has SELinux smarts builtin and does a policy check.

This access is called rootok on the passwd class.

 sesearch -A | grep rootok
   allow authconfig_t authconfig_t : passwd { passwd chfn chsh rootok crontab } ; 
   allow sysadm_t sysadm_t : passwd { passwd chfn chsh rootok crontab } ; 
   allow system_cronjob_t system_cronjob_t : passwd rootok ; 
   allow testpolicy_t testpolicy_t : passwd { passwd chfn chsh rootok crontab } ; 
   allow anaconda_t anaconda_t : passwd { passwd chfn chsh rootok crontab } ; 
   allow rpm_script_t rpm_script_t : passwd { passwd chfn chsh rootok crontab } ; 
   allow accountsd_t accountsd_t : passwd { passwd chfn chsh rootok } ; 
   allow firstboot_t firstboot_t : passwd { passwd chfn chsh rootok crontab } ; 
   allow rpm_t rpm_t : passwd { passwd chfn chsh rootok crontab } ; 
   allow kernel_t kernel_t : passwd { passwd chfn chsh rootok crontab } ; 
   allow realmd_consolehelper_t realmd_consolehelper_t : passwd { passwd chfn chsh rootok crontab } ; 
   allow initrc_t initrc_t : passwd rootok ; 
   allow unconfined_t unconfined_t : passwd { passwd chfn chsh rootok crontab } ; 
   allow livecd_t livecd_t : passwd { passwd chfn chsh rootok crontab } ; 
   allow openshift_initrc_t openshift_initrc_t : passwd { passwd chfn chsh rootok crontab } ; 
   allow zoneminder_t zoneminder_t : passwd { passwd rootok } ;

Thanks, Dan; how stupid of me not to look inside my own package.

So, everything seems fine and secure.