Bug 19944 - grub2 password set in drakboot does not protect booting of linux operating systems
Summary: grub2 password set in drakboot does not protect booting of linux operating sy...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: High major
Target Milestone: Mageia 6
Assignee: Barry Jackson
QA Contact:
URL: http://gitweb.mageia.org/web/doc/tree...
Whiteboard:
Keywords: 6RC
Depends on:
Blocks:
 
Reported: 2016-12-14 14:16 CET by Dick Gevers
Modified: 2017-05-17 02:11 CEST (History)
6 users (show)

See Also:
Source RPM: grub2-2.02-0.git10463.6.mga6.src.rpm
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.

Source RPM: drakxtools-backend-17.60-1.mga6; grub2-common-2.02.git10463.4.mga6 => drakxtools-17.65-1.mga6; grub2*-2.02.git10463.4.mga6
CC: sysadmin-bugs => marja11, zen25000
Component: Release (media or process) => RPM Packages
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=15930
Assignee: bugsquad => mageiatools
Summary: Even after closure of bug #15930 live install with grub2 password works not => Getting grub2 to ask for a password works neither during a Live install, nor when setting a password with drakboot in an installed system.

Marja van Waes 2016-12-14 21:25:55 CET

Summary: Getting grub2 to ask for a password works neither during a Live install, nor when setting a password with drakboot in an installed system. => Getting grub2 to ask for a password works neither during a Live install, nor after setting a password with drakboot in an installed system.

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

CC: (none) => yves.brungard_mageia

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

Summary: Getting grub2 to ask for a password works neither during a Live install, nor after setting a password with drakboot in an installed system. => drakboot.html and setupBootloader.html don't tell what the Grub2 password is for, which leads to wrong expectations.
Assignee: mageiatools => doc-bugs

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

Source RPM: drakxtools-17.65-1.mga6; grub2*-2.02.git10463.4.mga6 => drakxtools-curses-17.65-1.mga6
Assignee: doc-bugs => mageiatools

Dick Gevers 2016-12-17 09:38:14 CET

Summary: drakboot.html and setupBootloader.html don't tell what the Grub2 password is for, which leads to wrong expectations. => 'drakboot --boot' has stopped password protection of thee bootloader menu entries

Dick Gevers 2016-12-17 09:38:30 CET

Summary: 'drakboot --boot' has stopped password protection of thee bootloader menu entries => 'drakboot --boot' has stopped password protection of the bootloader menu entries

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 ;-)

Source RPM: drakxtools-curses-17.65-1.mga6 => drakxtools-17.65-1.mga6

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

Keywords: 6sta2 => 6RC
Source RPM: drakxtools-17.65-1.mga6 => drakxtools-17.77-1.mga6

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.

Priority: Normal => release_blocker

Comment 20 Rémi Verschelde 2017-04-26 11:43:08 CEST
@ Thierry, Barry: Would this be a missing feature of the grub2 integration in drakboot?

CC: (none) => thierry.vignaud

Comment 21 Barry Jackson 2017-04-27 01:17:15 CEST
(In reply to Rémi Verschelde from comment #20)
> @ Thierry, Barry: Would this be a missing feature of the grub2 integration
> in drakboot?

The setup of a grub2 password is explained in the POC procedure for https://bugs.mageia.org/show_bug.cgi?id=17334
which is based on the Ubuntu article that Dick linked in #14.

I am not sure if this is what Thierry implemented in #15930.
Comment 22 Frédéric Buclin 2017-05-14 02:05:42 CEST
This is not a bug in drakboot. It does its job correctly:

- when a password is set from drakboot, grub2 correctly asks for it to edit the menus and to access the command-line.

- This patch in grub2 explicitly mentions that "When we set a password, we just want that to mean you can't /edit/ an entry.":

http://svnweb.mageia.org/packages/cauldron/grub2/current/SOURCES/0045-Don-t-require-a-password-to-boot-entries-generated-b.patch?revision=1006390&view=markup&pathrev=1101004

It does this by explicitly passing --unrestricted to each menuentry, which means that users can select all menu entries without restrictions, by design.


So I'm closing this bug as invalid as it's not a bug in drakboot, and because grub2 behaves in the expected way.

Feel free to file a separate bug about grub2 if you think this behavior should be reverted, but it's not a release blocker.

CC: (none) => LpSolit
Resolution: (none) => INVALID
Status: NEW => RESOLVED

Comment 23 Frédéric Buclin 2017-05-14 02:29:29 CEST
For the record, note that https://help.ubuntu.com/community/Grub2/Passwords#Protecting_Menuentries states that:

"There is currently no automated method of adding users or designating menu items to be protected. The user must manually edit the GRUB 2 scripts."
Comment 24 Barry Jackson 2017-05-14 15:13:10 CEST
(In reply to Frédéric Buclin from comment #22)
> This is not a bug in drakboot. It does its job correctly:
> 
> - when a password is set from drakboot, grub2 correctly asks for it to edit
> the menus and to access the command-line.
> 
> - This patch in grub2 explicitly mentions that "When we set a password, we
> just want that to mean you can't /edit/ an entry.":
> 
> http://svnweb.mageia.org/packages/cauldron/grub2/current/SOURCES/0045-Don-t-
> require-a-password-to-boot-entries-generated-b.
> patch?revision=1006390&view=markup&pathrev=1101004
> 
> It does this by explicitly passing --unrestricted to each menuentry, which
> means that users can select all menu entries without restrictions, by design.
> 
> 
> So I'm closing this bug as invalid as it's not a bug in drakboot, and
> because grub2 behaves in the expected way.
> 
> Feel free to file a separate bug about grub2 if you think this behavior
> should be reverted, but it's not a release blocker.

Thanks for the clarification.
In this case I feel that the bug is in drakxtools help in the drakboot help file where the only explanation of the "Password" that is being set is:

"In the third and last part, called Security, it is possible to set a password."

Most users would assume that this is for setting a password required to launch a menu option in grub2 rather than to edit the script or use the command line.

It should be made more clear.

Re-opening.

Resolution: INVALID => (none)
Priority: release_blocker => Normal
Status: RESOLVED => REOPENED

Frédéric Buclin 2017-05-14 15:36:51 CEST

Target Milestone: --- => Mageia 6
Assignee: mageiatools => grenoya
URL: (none) => http://gitweb.mageia.org/web/doc/tree/mcc/5/en/content
Summary: 'drakboot --boot' has stopped password protection of the bootloader menu entries => Document that the password set in drakbook is only used protect the edition of the boot menu entries and to access the command-line, not to boot Mageia
Source RPM: drakxtools-17.77-1.mga6 => mageia-doc-5.9-1.mga6.src.rpm

Frédéric Buclin 2017-05-14 15:37:37 CEST

Summary: Document that the password set in drakbook is only used protect the edition of the boot menu entries and to access the command-line, not to boot Mageia => Document that the password set in drakbook is only used to protect the edition of the boot menu entries and to access the command-line, not to boot Mageia

Comment 25 Marja van Waes 2017-05-14 16:26:45 CEST
It's a bit more complicated.

For the Mageia boot entries, it is editing them that's password protected.

However, I cannot boot into windows 7 without entering a user name (root, iinm) and password.

I don't know about booting into other OSs. 

Re-assigning to documentation team.

Summary: Document that the password set in drakbook is only used to protect the edition of the boot menu entries and to access the command-line, not to boot Mageia => Document that the password set in drakboot is only used to protect the edition of the boot menu entries and to access the command-line, not to boot Mageia
Assignee: grenoya => doc-bugs

Comment 26 Barry Jackson 2017-05-14 19:29:15 CEST
(In reply to Marja van Waes from comment #25)
> It's a bit more complicated.
> 
> For the Mageia boot entries, it is editing them that's password protected.

Confirmed in a clean install (PC-BIOS, x86_64, LXDE, in VBox, with Win_8.1 alongside)

> 
> However, I cannot boot into windows 7 without entering a user name (root,
> iinm) and password.

Confirmed - root and root PW required to boot Win.

Strange :\
Comment 27 Marja van Waes 2017-05-14 19:38:22 CEST
(In reply to Barry Jackson from comment #26)
> (In reply to Marja van Waes from comment #25)

> 
> > 
> > However, I cannot boot into windows 7 without entering a user name (root,
> > iinm) and password.
> 
> Confirmed - root and root PW required to boot Win.
> 
> Strange :\

for me the password is not the root passwd, but the password that i set with drakboot
Comment 28 Barry Jackson 2017-05-14 21:33:22 CEST
(In reply to Marja van Waes from comment #27)
> (In reply to Barry Jackson from comment #26)
> > (In reply to Marja van Waes from comment #25)
> 
> > 
> > > 
> > > However, I cannot boot into windows 7 without entering a user name (root,
> > > iinm) and password.
> > 
> > Confirmed - root and root PW required to boot Win.
> > 
> > Strange :\
> 
> for me the password is not the root passwd, but the password that i set with
> drakboot

Possibly.
I stupidly used the same password (as it's the only I can remember).
Comment 29 Barry Jackson 2017-05-15 01:21:48 CEST
Changing the PW confirms it is the one set in drakboot.
Comment 30 Barry Jackson 2017-05-15 16:11:06 CEST
I have found a little time to look closer at this issue.

This IS a drakboot bug.

In order for the password to protect the Linux/Mageia menu entries *from booting without a password* drakboot needs to edit /etc/grub.d/10_linux and
remove "--unrestricted" from the line:

CLASS="--class gnu-linux --class gnu --class os --unrestricted"

Also if the password is removed this should be put back again.

This should also be followed by a grub2-mkconfig -o /boot/grub2/grub.cfg

This then prompts for user 'root' and the password entered in drakboot.

So I think this needs to be fixed in drakboot and the original bug title restored. Also the documentation edits need a re-think.

Summary: Document that the password set in drakboot is only used to protect the edition of the boot menu entries and to access the command-line, not to boot Mageia => grub2 password set in drakboot does not protect booting of linux operating systems

Barry Jackson 2017-05-15 16:13:49 CEST

Source RPM: mageia-doc-5.9-1.mga6.src.rpm => drakxtools-17.82-1.mga6.src.rpm

Barry Jackson 2017-05-15 16:15:52 CEST

Priority: Normal => release_blocker
Assignee: doc-bugs => thierry.vignaud
Severity: normal => major

Comment 31 Frédéric Buclin 2017-05-15 16:19:40 CEST
I disagree, this is not how things work. Re-read my comment 22 and the patch mentioned there. It explicitly mentions that the password is to prevent menu entries edition, not to prevent booting. So things work as designed.
Comment 32 Barry Jackson 2017-05-15 16:31:26 CEST
Ah right, so we need to remove that RedHat patch to make things work as expected.
This what happens when we follow Fedora too closely.
Comment 33 Nicolas Lécureuil 2017-05-15 16:44:01 CEST
i would set this to high but not release blocker.

I don't know the package enough to comment about the patch btw.

CC: (none) => mageia

Comment 34 Barry Jackson 2017-05-15 16:59:09 CEST
(In reply to Nicolas Lécureuil from comment #33)
> i would set this to high but not release blocker.
OK

> 
> I don't know the package enough to comment about the patch btw.

I will assign this to me and I will remove the patch from grub2 and push it after some more testing. It was added by Thierry about 12 months ago in a block of Fedora patches, and it's significance was probably not realized at the time.

Priority: release_blocker => High
Assignee: thierry.vignaud => zen25000
Source RPM: drakxtools-17.82-1.mga6.src.rpm => grub2-2.02-0.git10463.6.mga6.src.rpm

Comment 35 Frédéric Buclin 2017-05-15 17:12:33 CEST
Removing the patch is not enough. You must add --users "" to CLASS when a password is set and replace it by --unrestricted when no password is set.

So you will have to write a patch for /etc/grub.d/10_linux to make it look at GRUB2_PASSWORD in /boot/grub2/user.cfg.
Comment 36 Barry Jackson 2017-05-15 19:21:33 CEST
(In reply to Frédéric Buclin from comment #35)
> Removing the patch is not enough. You must add --users "" to CLASS when a
> password is set and replace it by --unrestricted when no password is set.
> 
> So you will have to write a patch for /etc/grub.d/10_linux to make it look
> at GRUB2_PASSWORD in /boot/grub2/user.cfg.

There is no mention of --users '' being required here:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sec-Protecting_GRUB_2_with_a_Password.html

I think --users is for the more complex cases where different passwords are assigned to different user names, although the documentation is a mess. In Our simple case only 'root' is allowed who uses the password set in drakboot to access all systems.

I tested simply removing --unrestricted last night and it worked OK for me in a VM to access Mageia alongside Win8.1 which already required 'root' and the password. Without --unrestricted Mageia worked in just the same way as Win.
Comment 37 Frédéric Buclin 2017-05-15 19:45:13 CEST
I was reading this documentation:

https://www.gnu.org/software/grub/manual/grub.html#Security

which gives this example:

menuentry "Superusers only" --users ""


But in the previous paragraph, it mentions that "If the --users option is not used for a menu entry, then that only superusers are able to use it.", so it seems that --users is indeed not needed. In that case, it would have been nice to write an example which is consistent with the documentation. :)

So ok, you are right, --users "" is not needed. It only makes clearer that nobody can boot except superusers.
Comment 38 Barry Jackson 2017-05-15 21:33:48 CEST
Fixed in Cauldron - submitted.

Closing

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

Comment 39 Frédéric Buclin 2017-05-15 23:22:56 CEST
While you are on it, wouldn't it make sense to package the stable grub 2.02? This means using:

Source0: ftp://ftp.gnu.org/gnu/grub/grub-%%{tarversion}.tar.xz

with tarversion = 2.02 instead of 2.02~beta3.

Psychologically, I'm personally not a fan to use a snapshot of a software (grub2-2.02-0.git10463.7.mga6).
Comment 40 Barry Jackson 2017-05-16 00:10:22 CEST
(In reply to Frédéric Buclin from comment #39)
> While you are on it, wouldn't it make sense to package the stable grub 2.02?
> This means using:
> 
> Source0: ftp://ftp.gnu.org/gnu/grub/grub-%%{tarversion}.tar.xz
> 
> with tarversion = 2.02 instead of 2.02~beta3.
> 

Not really - it isn't currently broken and now is not the time to break it.

> Psychologically, I'm personally not a fan to use a snapshot of a software
> (grub2-2.02-0.git10463.7.mga6).

Me neither, but it's virtually impossible to avoid using snapshots with grub2 releases being so far (several years) apart.

We currently carry about 85 patches for grub2 from many different sources and I am sure many of them will fail to apply if we try to update.

I may take a look at it after Cauldron re-opens but not before. :)
Comment 41 Thierry Vignaud 2017-05-17 00:39:28 CEST
(In reply to Barry Jackson from comment #34)
> I will assign this to me and I will remove the patch from grub2 and push it
> after some more testing. It was added by Thierry about 12 months ago in a
> block of Fedora patches, and it's significance was probably not realized at
> the time.

Please stop lying...

1) I did _NOT_ added it 12 months ago.
2) _YOU_ added it 20 months ago:
http://svnweb.mageia.org/packages/cauldron/grub2/current/SOURCES/0039-Don-t-require-a-password-to-boot-entries-generated-b.patch?revision=873987&view=markup&pathrev=990770

I only renamed it & added the RH header (comments) in order to reduce the diff noise with FC.

Following history isn't that hard...
Please do not blame me for what you did.
Thanks.

Angry dad is tired of people always blaming the installer or the tools for bugs in other packages (eg this one or the recent fbdev issue which was caused by dkms...)
Comment 42 Barry Jackson 2017-05-17 01:39:41 CEST
I was not lying, or blaming, only explaining how I thought it happened.
I was wrong, my mistake.
I did not look far enough back.
Sorry.
Comment 43 Dick Gevers 2017-05-17 02:11:03 CEST
Besides, not every tester has experience or expertise to ascertain the cause when something seems to fail during use of the installer. So yes, blaming installer is sometimes my default reaction to attach blame. So sorry for that ! 

On the other hand I *am* please there is a new Vignaud who may help us all with similar issues in the future..... ;))))

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