Re: Grub2 Security

[Andrei Borzenkov]

В Sat, 30 May 2015 11:37:37 +0100
Joāo Ricardo Sares Teles de Matos <address@hidden> пишет:

> Is there no difference between an "unset variable" and a variable set to an 
> empty string, or are both cases just treated the same in this particular 
> situation?

I apologize for confusion. On GRUB CLI level there is no difference
between "unset" and "empty" indeed - you can only check whether
result of variable substitution ($foo) is empty or not and it is empty
in both cases.

In this particular case grub internally does distinguish between empty
and non set ``superusers'' variable. So using

set superusers=

effectively disables access to CLI and menu editing.

> Either of those would warrant a clarification in the manual.
> 

I tried to change description to make it explicit that empty superusers
disabled CLI and menu edit. As for variables on CLI - I think it is
implicit in that there is no syntax to check whether variable is set.

> On May 30, 2015 5:46:44 AM GMT+01:00, Andrei Borzenkov <address@hidden> wrote:
> >В Sat, 30 May 2015 01:23:32 +0100
> >Joāo Ricardo Sares Teles de Matos <address@hidden> пишет:
> >
> >> On second thought...
> >> "If ‘superusers’ is set, then use of the command line is
> >automatically restricted to superusers."
> >> 
> >> Setting an empty superusers list and adding --unresticted to your
> >entries is probably what you want.
> >> 
> >
> >Empty $superusers is treated the same as no $superusers. GRUB
> >translates legacy menu.lst clause into "superusers=legacy" to assign
> >it /some/ value. In general, just set superusers to any non-empty
> >string and do not define any user and password. 
> >
> >> On May 30, 2015 1:05:28 AM GMT+01:00, "Joāo Ricardo Sares Teles de
> >Matos" <address@hidden> wrote:
> >> >It's right here:
> >> >https://www.gnu.org/software/grub/manual/grub.html#Security
> >> >Set a superuser that can't actually be used and use --unrestricted
> >on
> >> >the entries.
> >> >
> >> >How to set up an "unauthenticatable" superuser is my question.
> >> >Maybe setting an invalid password hash with password_pbkdf2 or just
> >not
> >> >setting the user's password will suffice.
> >> >
> >> >On May 29, 2015 10:28:17 PM GMT+01:00, "Boyce, Kevin P. (AS)"
> >> ><address@hidden> wrote:
> >> >>All,
> >> >>
> >> >>I am hoping someone can help me with a grub2 configuration
> >question. 
> >> >I
> >> >>
> >> >>would like to be able to secure grub menu entries from being
> >modified.
> >> >>I do not want to have to enter a password to boot the system (which
> >
> >> >>doesn't appear to be the current behavior of grub2 when set 
> >> >>superusers="root" directive is used).
> >> >>I do not want to have to create users and associated passwords
> >(null 
> >> >>password is OK).
> >> >>
> >> >>I would like everyone to be able to select either one of these two
> >> >boot
> >> >>
> >> >>entries without the need for a password, but i do not want them to
> >be 
> >> >>able to enter command mode or edit mode in which they could boot
> >> >single
> >> >>
> >> >>user mode (my Rescue enviroment is being customized for recovery
> >> >>purposes).
> >> >>
> >> >>My bootloader and configuration will be permanently installed in a 
> >> >>read-only device like ROM and never changed.  I use the configfile 
> >> >>directive to point to the real bootloader configuration on a
> >different
> >> >
> >> >>device I want to use.
> >> >>
> >> >>Here is my current config file, documentation on grub2 security
> >seems
> >> >a
> >> >>
> >> >>little lacking.  I recall being able to achieve this behavior by
> >using
> >> >
> >> >>the lock directive in legacy-grub.
> >> >>Any help would be appreciated.
> >> >>
> >> >>Thanks,
> >> >>Kevin
> >> >>
> >> >># Load GPT Partition Support
> >> >>insmod part_gpt
> >> >>
> >> >># Load XFS File System Support
> >> >>insmod xfs
> >> >>
> >> >># Load EXT File System Support
> >> >>insmod ext2
> >> >>
> >> >># Set a timeout before we pick the default
> >> >>set timeout=7
> >> >>
> >> >># Set the default boot entry
> >> >>set default="0"
> >> >>set fallback="1"
> >> >>
> >> >># Don't want any accounts that can bypass either one of these two
> >> >>entries
> >> >>set superusers=""
> >> >>
> >> >># Default boot entry redirecting to config file on RAID
> >> >># Secure without granting users permission to modify
> >> >>menuentry "Redirect Boot to RAID Device" --users "" {
> >> >>     search --no-floppy --set=root --label RAID
> >> >>     configfile /.firmware/boot.cfg
> >> >>}
> >> >>
> >> >># Create an entry for loading troubleshooting environment
> >> >># Secure without granting users permission to modify this entry
> >> >>menuentry "Rescue" --users "" {
> >> >>     search --no-floppy --set=root --label RESCUE
> >> >>     linux /vmlinuz rescue
> >> >>     initrd /initrd.img
> >> >>}
> >> >>
> >> >>_______________________________________________
> >> >>Help-grub mailing list
> >> >>address@hidden
> >> >>https://lists.gnu.org/mailman/listinfo/help-grub
> >> >
> >> >-- 
> >> >Typed with a virtual keyboard. Please excuse any blunders.
> >> >
> >>
> >>------------------------------------------------------------------------
> >> >
> >> >_______________________________________________
> >> >Help-grub mailing list
> >> >address@hidden
> >> >https://lists.gnu.org/mailman/listinfo/help-grub
> >> 
>