Bug 1045574 - [GSS 7.0] Create new dracut module to ease recovery of lost root password [NEEDINFO]
Summary: [GSS 7.0] Create new dracut module to ease recovery of lost root password
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: distribution
Version: 7.0
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Terry Bowling
QA Contact: Nobody
URL: http//
Whiteboard:
Depends On:
Blocks: 1113520 1130820 1203710
TreeView+ depends on / blocked
 
Reported: 2013-12-20 18:28 UTC by Andrius Benokraitis
Modified: 2019-02-28 18:54 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1085821 1130820 (view as bug list)
Environment:
Last Closed: 2019-02-28 18:54:44 UTC
salmy: needinfo? (tbowling)


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1192 None None None Never

Description Andrius Benokraitis 2013-12-20 18:28:43 UTC
Changing a lost root password is significantly more complicated compared to RHEL 6. Granted, if one has the rescue ISO, this isn't as bad, but if you don't have the rescue ISO - SELinux has a habit of getting in the way, and would be great if we didn't have to relabel the entire system for only a few files.

Request: Create a new dracut module specifically for trying to recover a lost root password via a new:
init=/bin/forgotrootpasswd
which requires /bin/forgotrootpasswd to carry all of the knowledge of how to mount / and any other required filesystems, which dracut should already know about. The nice thing about this solution is that a full re-label won't be necessary, only /etc/passwd and /etc/shadow.

Comment 4 Harald Hoyer 2014-01-07 14:49:42 UTC
Why don't you use "init=/bin/bash rw" ?? Which mounts the root filesystem writeable and starts a shell?

dracut should not be needed for that.

Comment 5 Andrius Benokraitis 2014-01-28 16:01:01 UTC
Comments from ablum:

It seems that when you pass 'init=/bin/bash' to the kernel in GRUB and 
change any file, that file will end up with file_t as context.  Here is one
of the other files I changed:

-rw-r--r--. root root system_u:object_r:file_t:s0
/lib/systemd/system/rescue.service

So, the real problem is not so much a selinux issue, per se.  It's more of
a catch-22 caused by the move to sulogin in rescue.service vs. sushell.
You are trying to change the root password [b/c you don't know it] but you
are being prompted for it by sulogin.  When you work around this with
'init=/bin/bash' you end up with files with file_t context which then
causes some problems.

So, the question I think we are asking is, what should be the recommended
way to reset the root password when you do not have physical media ?

1. Boot with 'init=/bin/bash' argument
2. mount -o remount,rw /
3. passwd root
4. touch /.autorelabel
5. Restart the system.  The system relabels and then reboots
automatically.

Doesn't this make the assumption that the customer has maintained file
context mapping definitions across the whole system [via semanage
fcontext] ?

I guess it just makes me kind of nervous.  What if the cu has altered
file contexts for a specific service without semanage ?  Couldn't an
autorelabel cause a problem in those cases ?

Could we be more specific with which files need their contexts
relabeled ? In the procedure given by Paul Frields, /etc/shadow would be one.

Regards, 

-- Andrew Blum, RHCA RHCX GSS Training Content Developer

Comment 6 Harald Hoyer 2014-01-28 16:13:56 UTC
I'll reassign this to distribution.

If you want a pw-less shell, then introducing a sushell.service might make more sense, than dracut changes.

Bill?

Comment 7 Bill Nottingham 2014-01-28 16:21:47 UTC
I guess we could have a disabled service for this, but it seems weird to me to require the administrator to set up a specific service to make their system less 'secure' in this way - if they're setting up the system in this way, they're likely able to change their password correctly.

WRT SELinux, doesn't load_policy work from init=/bin/bash?

Comment 8 Václav Pavlín 2014-03-11 11:53:34 UTC
I tried to use load_policy as Bill suggested in comment #7 and files seem to be labeled correctly.

So if I use Andrius' steps:

1. Boot with 'init=/bin/bash' argument
2. /usr/sbin/load_policy
3. mount -o remount,rw /
4. passwd root
5. Restart the system. System boots and user is able to login correctly in enforcing mode.

Is this sufficient solution?

Comment 9 RHEL Product and Program Management 2014-03-24 05:49:44 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 10 Andrius Benokraitis 2014-03-24 19:25:57 UTC
This is probably sufficient, but let's wait to see what customers say about this. Obviously a new dracut module would be the best experience, but let's see what people say.

I've updated:

https://access.redhat.com/site/solutions/1192

to reflect this.

Comment 11 Andrew Blum 2014-04-08 19:22:46 UTC
Yes, load_policy worked for me without having to reboot or relabel.

Should we use the -i option with load_policy ? Passing no argument returns:

"Can't load policy: No such file or directory"

Also, shouldn't we also remount root to read-only after the change before killing the bash shell..maybe that's being too cautious ?

1. Boot with 'init=/bin/bash' argument
2. /usr/sbin/load_policy -i
3. mount -o remount,rw /
4. passwd root
5. mount -o remount,ro /
6. Restart the system. System boots and user is able to login correctly in enforcing mode.

Thanks for your help.
--
Andrew

Comment 13 Václav Pavlín 2014-07-08 17:15:53 UTC
Is this issue solved? I am not sure what else I can do from distribution component point of view.

Comment 18 Andrius Benokraitis 2014-08-05 12:56:14 UTC
Setting needinfo on cpelland, my replacement in GSS.


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