Bug 19944 - 'drakboot --boot' has stopped password protection of the bootloader menu entries
Summary: 'drakboot --boot' has stopped password protection of the bootloader menu entries
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
: release_blocker normal
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard:
Keywords: 6RC
Depends on:
Blocks:
 
Reported: 2016-12-14 14:16 CET by Dick Gevers
Modified: 2017-04-09 12:19 CEST (History)
3 users (show)

See Also:
Source RPM: drakxtools-17.77-1.mga6
CVE:
Status comment:


Attachments
stdout from "journalctl -ab" command at the end of Live install (42.75 KB, application/x-xz)
2016-12-14 14:22 CET, Dick Gevers
Details
journal from installed m6sta2 (59.82 KB, application/x-xz)
2016-12-14 14:28 CET, Dick Gevers
Details
recording password during live install (83.12 KB, image/png)
2016-12-14 14:31 CET, Dick Gevers
Details
Boot entries available in first reboot (20.53 KB, image/jpeg)
2016-12-14 14:34 CET, Dick Gevers
Details
trying "Advanced options for Mageia" with user Live and previously chosen password (21.58 KB, image/jpeg)
2016-12-14 14:36 CET, Dick Gevers
Details
boot choice "Mageia" boots without password (22.66 KB, image/jpeg)
2016-12-14 14:37 CET, Dick Gevers
Details

Description Dick Gevers 2016-12-14 14:16:16 CET
Installed M6sta2 in Live mode from all 4 DVD's (2 from optical disk, 2 from usb) and with 2 or 3 I tried recording a password in the bootloader-grub2 entry fields that apply. (Screenshot to eb added)

However when next rebooting the live user is the only one known and the password is not accepted for the second bootmenu choice "Advanced options for Mageia", while the first entry ("Mageia") boots immediately without asking a password.

Frankfly I did not try entering a password in classical install yet, maybe it works there. 
If this only fails in all Lives it should be fixed or written to errata. Will try classical after next build now nearly ready.
Comment 1 Dick Gevers 2016-12-14 14:22:45 CET
Created attachment 8770 [details]
stdout from "journalctl -ab" command at the end of Live install
Comment 2 Dick Gevers 2016-12-14 14:28:46 CET
Created attachment 8771 [details]
journal from installed m6sta2

This was obtained from current cauldron after first reboot in M6sta2 and subsequent boot to current cauldron, mounting /mnt/beta and cd to /mnt/beta/var/log/journal/blabla/ and giving command: journalctl -a -D .
Comment 3 Dick Gevers 2016-12-14 14:31:44 CET
Created attachment 8772 [details]
recording password during live install
Comment 4 Dick Gevers 2016-12-14 14:34:34 CET
Created attachment 8773 [details]
Boot entries available in first reboot
Comment 5 Dick Gevers 2016-12-14 14:36:22 CET
Created attachment 8774 [details]
trying "Advanced options for Mageia" with user Live and previously chosen password
Comment 6 Dick Gevers 2016-12-14 14:37:06 CET
Created attachment 8775 [details]
boot choice "Mageia" boots without password
Comment 7 Dick Gevers 2016-12-14 14:38:25 CET
The rpm's chosen are those listed for this iso (plasma 32 bits dated 10.DEC.2016)
Comment 8 Dick Gevers 2016-12-14 14:51:27 CET
I have saved /boot/grub and /etc/grub.d which can be attached upon request or given a URL for /boot (too large to attach)
Comment 9 Marja van Waes 2016-12-14 21:25:18 CET
Running drakboot in an installed cauldron and adding a password with it, doesn't result in needing to type a password when booting the same cauldron, either.

I didn't see anything related to a password in the diff of grub.cfg and grub.cfg.old, nor in the diff of grub.env and grub.env.old, but forgot to check the time stamp of the .old files when I did that :-( 

/boot/grub2/user.cfg was correctly created 

-rw------- 1 root root   297 dec 14 20:47 user.cfg

Making the file world readable didn't help :-þ
(and then running update-grub2 and grub2-install again, didn't help either)

@ Dick

if you still have /boot/grub2/*.old files from before adding the password, can you then please diff them with the new files?



I don't know when this feature stopped working, I never tried to use it before, because I can set my BIOS to request a password to boot anything.
Comment 10 Dick Gevers 2016-12-15 00:00:09 CET
@(In reply to Marja van Waes from comment #9)

I cannot have an *.old file because Live provides only new installs and with latest classical isos I hadn't noticed that bug #15930 had been fixed. Will try this with next classical isos (currently building I heard), unless someone beats me to it.

(Your reason for not trying is less good if someone can take out the BIOS battery: that will probably revert the BIOS to original password-free settings).
Comment 11 papoteur 2016-12-15 18:29:51 CET
Another user reported to have the non working password in grub:
https://www.mageialinux-online.org/forum/topic-22866+mot-de-passe-au-lancement-de-mageia-et-sortie-de-veille.php
Comment 12 Marja van Waes 2016-12-17 08:48:34 CET
It seems we misunderstood what the password is for /o\

We should have better read the second comment in bug 15930
https://bugs.mageia.org/show_bug.cgi?id=15930#c2

> commit 9bb701c386fcb05068c4c02b372e0c0b754995b3
> Author: Thierry Vignaud <thierry.vignaud@...>
> Date:   Tue Jun 21 17:21:13 2016 +0200
> 
>     grub2: enable to protect with a password
>     
>     thus restricting altering the config on boot (mga#15930)

It doesn't prevent starting a boot entry, it only prevents *editing* a boot entry. That is indeed impossible without giving the username root (I only tried root, because root is the only one who can read user.cfg) + the created password, and that works fine.

It looks like we have something to add to our documentation!

Reassigning to documentation team.

Btw, it should be possible to manually restrict who can start a boot entry, see:
https://www.gnu.org/software/grub/manual/html_node/Security.html#Security
Comment 13 Marja van Waes 2016-12-17 09:31:03 CET
(In reply to Dick Gevers from comment #10)

> (Your reason for not trying is less good if someone can take out the BIOS
> battery: that will probably revert the BIOS to original password-free
> settings).

Didn't happen on my oldest ThinkPad, where I replaced the BIOS battery half a year after it died. The password was needed all the time, even to start a Live iso. I'll keep in mind that that isn't a guarantee for later ThinkPads, though ;-).
Comment 14 Dick Gevers 2016-12-17 09:34:39 CET
(In reply to Marja van Waes from comment #12)

> It seems we misunderstood what the password is for /o\

I do not quite agree: see below.
 
> We should have better read the second comment in bug 15930

> >     grub2: enable to protect with a password
> >     thus restricting altering the config on boot (mga#15930)

I get the meaning, so indeed 15930 is fixed. But the "drakboot --boot" has always (and this should not change) password protected the bootloader, be it lilo, grub legacy and should with grub2. 

And it is possible, witness 1 exampel: https://help.ubuntu.com/community/Grub2/Passwords

> It looks like we have something to add to our documentation!

No not for me.

> Btw, it should be possible to manually restrict who can start a boot entry,
> see:
> https://www.gnu.org/software/grub/manual/html_node/Security.html#Security

So it is not an enhancement but just getting back to what drakboot has usually been able to do (I think I remember requesting Pixel for a fix when we came from lilo to grub legacy in mdk/mdv and it fell out ;)

In fact IMHO it is a security issue and triage should judge it more important :P
Comment 15 Marja van Waes 2016-12-17 09:44:52 CET
(In reply to Dick Gevers from comment #14)

> 
> So it is not an enhancement but just getting back to what drakboot has
> usually been able to do (I think I remember requesting Pixel for a fix when
> we came from lilo to grub legacy in mdk/mdv and it fell out ;)
> 
> In fact IMHO it is a security issue and triage should judge it more
> important :P

Whatever :-þ

Btw, the "Source RPM:" field is about the SRPM. It does not mean "the rpm that's the source of the problem", so not the RPM name is needed, but the SRPM it originates from ;-)
Comment 16 Marja van Waes 2017-04-01 13:56:28 CEST
@ Dick

Forgot to tell: When trying to login to Windows, Grub2 did ask for a username (= root) and password here.
Comment 17 Dick Gevers 2017-04-01 14:44:20 CEST
Marja, I am sure you are right, but I haven't used Windows since 14 years myself ;)
Comment 18 Dick Gevers 2017-04-09 12:15:20 CEST
Applies to 6RC Live isos of 03 April 2017
Comment 19 Dick Gevers 2017-04-09 12:19:24 CEST
As Martin suggested on the QA ML I mark this as release blocker. Feel free to disagree: that is my opinion.

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