It does not help too much. Documented already. But for completeness sake, first step might be documenting how to configure a Bootloader Password.
Second step might be development of a tool which simplifies adding a bootloader password.
There is grub2-setpassword but unavailable in Debian.
It may be worth asking, do we want this to be separate from the user password? Having a bootloader password makes little sense if the user account isn’t password-protected and passwordless sudo is available. Similarly, for unencrypted systems, having a user password isn’t very helpful if the bootloader has no password set. Lastly, for most users, it probably makes sense for the bootloader and admin user passwords to be the same. So perhaps the tool that does this should set user and bootloader passwords?
I don’t see the strong connection between those.
Bootloader password + FDE + user auto login might make sense?
Because the bootloader password is a minor Protection against Physical Attacks.
I guess an argument could be made why it should be different but then “100” different passwords is bad usability. Those who insist on different passwords for everything should be able to set them. But if we provide a tool to easily set up a GRUB password, using the same password as user user or admin (?) might make sense.
Right, probably best if same by default.
The difference is only something we should document.
Should the GRUB bootloader, if unavailable:
Just for everyone else reading (as you probably know that)… As per Linux / GRUB default - unspecific to Kicksecure - technically there are many different passwords available… At least…
user passwordadmin passwordroot passworduser passwordroot passwordThese are all independent, stored in different “places”.
In theory nice, but when changing 1 password (such as the Linux user account admin password), coudln’t the GRUB bootloader (root) password get desync? That could be confusing.
In theory, always asking for a bootloader password might make most sense. This lowers the chance that the user will forget the password when needed. (If never asked for GRUB user password but then 1 year later being asked for GRUB root password could be an issue.)
It might help to clarify under what situations a bootloader password provides a meaningful level of additional security. From my standpoint, you have to have at least a bootloader password, a root password, and a BIOS password for it to be useful at all (the root password keeps you from gaining privileges when powered on, the bootloader password keeps you from gaining privileges by rebooting and entering recovery mode, and the BIOS password keeps you from gaining privileges by rebooting into an OS on an external drive). At that point you have to take the drive out of the victim computer in order to attack it easily.
With FDE, the bootloader password is only able to help prevent an attacker from easily modifying the contents of the disk blindly, and it still needs to be combined with a BIOS password to do that effectively.
I don’t see a whole lot of value in enabling a bootup password. That should be FDE’s job. On systems with soldered storage, a bootup password might complicate attacks, but FDE can do the same thing with all systems, even if those systems use non-soldered storage like a SATA or NVMe drive. I do see value in pairing a BIOS password with a bootloader password that prevents config modifications or boot menu access though, since the attacker now at least has to remove the storage drive from the victim system in order to tamper with the disk contents. The memory issue you bring up is helpful, but as long as the bootloader and admin passwords are the same, that should help avoid memory problems.
If you have passwordless sudo, you can just sudo -i and then remove the bootloader password or change bootloader config as you see fit. Granted, FDE would protect against that.
If paired with a BIOS password, I think so.
Yeah, that’s a decent point. If our app was the canonical “how to change your password” app in Kicksecure, that would help prevent that problem, but then there’s probably a feature in XFCE that will change only just the user password, and of course passwd exists. Not sure how to deal with that…
It might help to clarify under what situations a bootloader password provides a meaningful level of additional security.
Right.
I am documenting that here: Bootloader Password
From my standpoint, you have to have at least a bootloader password, a root password, and a BIOS password for it to be useful at all (the root password keeps you from gaining privileges when powered on, the bootloader password keeps you from gaining privileges by rebooting and entering recovery mode, and the BIOS password keeps you from gaining privileges by rebooting into an OS on an external drive).
Doesn’t a BIOS password alone already prevent all of that and requires taking out the drive or some other physical attack?
Well, one could add the assumption that the adversary has a BIOS password bypass. Then the bootloader password might help. This might be an unrealistic assumption.
I think a BIOS password + FDE pre boot authentication password is sufficient “in most cases”.
Then surely the question will come up “in which cases it does not suffice?” The answer is most likely, in complex cases which are not applicable to the reader, because if these were applicable, the question would not come up. One case that can be constructed is some sort of corporate setup.
For example, an employee is given a BIOS password for booting from the internal hard drive, but not from other devices. Furthermore, the employee is allowed to boot using the standard/default option but prevented from booting the recovery boot option, because that password would be retained for system administrators only.
That reminds me of, quote xkcd: Authorization
If someone steals my laptop while I’m logged in, they can read my email, take my money, and impersonate me to my friends, but at least they can’t install drivers without my permission.
But more seriously…
I guess it depends on the threat model. Physical attacks while powered on are always a very high risk situation.
I however was thinking of BIOS password, bootloader password, FDE password, Linux user password, Linux root/sudo password in terms physical attacks while the machine is powered off.
A BIOS password alone will stop most non-technical attackers. More technical attackers who steal the hard drive would be stopped by FDE. That’s why BIOS password + FDE always seemed to be as the most important passwords.
If a physical attacker gets to run (passwordless) sudo, as mentioned in the xkcd, I might not mind much, as most sensitive data is accessible already when logged in as user (not root).
the bootloader password keeps you from gaining privileges by rebooting
But a reboot will go through BIOS or are you referring to kexec? (I don’t know if GRUB can be load somehow using kexec.)
Good, you could say not having a sudo password will allow a physical attacker to run kexec. But is that even still neeed? → xkcd
In that threat model that I am considering here now, physical attacks while powered are excluded. [1]
Right. I would exclude that form that threat model anyhow due to xkcd.
In conclusion, the bootloader password seems to only make sense in niche cases.
Please correct me if I am wrong. Happy to present the full threat model analysis in the wiki.
[1] For physical attacks while powered on:
I think I see where I’m misunderstanding - I’m thinking of using BIOS and bootloader passwords specifically for preventing access to advanced configuration settings, i.e. the system can be booted without either password, but dropping to a GRUB shell or booting from an external drive using the BIOS should require one of the system passwords. In this context the passwords are only useful for preventing unauthorized root access and denying the ability to tamper with the system’s storage without removing the internal drive. Thus ability to gain root access on an unencrypted system has been the threat I’ve been considering most strongly. I think you’re thinking about these passwords being used to prevent even bootup, such that the system is essentially bricked unless you possess both BIOS and bootloader passwords. This way the passwords are used not just to prevent unauthorized root, but as a form of authentication to even use the system. We should decide on which one we’re discussing so that we’re both talking about the same thing.
If the BIOS password only prevents getting into BIOS options, no, it does not. One simply has to drop to a GRUB console (trivially doable on many EFI systems by repeatedly pressing Esc during bootup) and they can then boot any arbitrary OS by hand, including one provided on an external USB drive. Similarly, if you have a bootloader password but not BIOS password, you can trivially bypass it by booting from an external drive using the BIOS’s boot functionality. Only password-protecting both seriously complicates attacks that involve booting from an external drive.
If the BIOS password prevents booting the machine too, then yes, it does do all of that already. But in that situation a bootloader password isn’t all that useful, except as defense-in-depth against a relatively unskilled adversary. (Granted, most adversaries most of our users encounter will be relatively unskilled, and I can definitely imagine someone who can figure out a BIOS password reset via an article from the Internet but who can’t figure out how to get past a bootloader password.)
I think this is applicable to everyday users too though, whether you’re requiring passwords for bootup or for config access. Depending on the difficulty of opening a device, being forced to take the drive out of the machine to modify it is a very significant hurdle that an attacker may not have the opportunity to carry out (i.e. someone who gains physical access to a machine but only for a very short period of time, and who has to leave the machine more-or-less intact once their attack is complete, this is basically the classic evil maid scenario). Some machines even have soldered internal storage, especially cheap, lightweight devices like “HP Stream” and “onn.” machines - this makes this class of attack nearly impossible without access to advanced, expensive equipment for desoldering the storage chips and resoldering them onto something that allows reading and writing them.
The bootloader password is still valuable though, even against a non-technical attacker, if the passwords are being used to prevent bootup entirely. Many machines have a manufacturer-provided backdoor for resetting BIOS passwords, and tools for exploiting these backdoors are publicly available on the open Internet (https://bios-pw.org/ is a good example). For machines such as this, a non-technical attacker can probably bypass the BIOS password easily enough, but then they have the bootloader password to contend with. Obviously at this point an attacker with slightly more skill would insert a live USB into the victim machine and boot from that, but there are plenty of attackers who lack that skill, especially in domestic abuse situations, so this still seems valuable to me, even if the benefits are limited at best.
But a reboot will go through BIOS or are you referring to kexec? (I don’t know if GRUB can be load somehow using kexec.)
I meant a reboot that goes through BIOS. Assuming the system is not password-protected, you can easily gain a root shell on Kicksecure without the root or user passwords by following Recovery - Kicksecure. An FDE password prevents this though.
Yes.
Not necessarily.
I guess sorta, though any attacker with the skill needed to move a drive between laptops probably also has the skill needed to boot a live USB to bypass the bootloader password. FDE would be much more important here, agreed.
There are many different options.
These can be different passwords. Administrator password can usually clear/change power-on password and is also allowed to boot.
In this discussion, I was revering to F) BIOS power-on password, a password that is required for every boot.
This was my assumption.
Right. The the protection provided by the BIOS power-on password isn’t that great. It’s a “hardware magic feature”. Some BIOS can be reset with:
There might be some BIOS resistant to that, designed to not easily being reset, but that is dependent on the hardware producer and may be dependent on the BIOS settings.
Yes.
GRUB bootloader password to prevent all boot menu entries could be considered more secure than BIOS power-on password, because it’s not a “hardware magic feature” but instead a software feature implemented in Freedom Software, GRUB.
Right.
I think I like the idea, especially in combination with disabling “easy” recovery mode and the Dracut recovery console. I think the only thing I’d really like to add to all of the above is that we document how to make the Dracut recovery console available again. I’ve used it for multiple debugging sessions that would have been rendered impossible or close to impossible without it. Let’s go with requiring the password on every boot since that provides substantial benefits over just locking out the configuration options.
We should be careful with calling it more secure IMO - the bootloader password may be harder to bypass, but the BIOS password is necessary to complicate attacks that involve booting from an external USB drive. They both have their pros and cons, and ideally should be used together.
Also, we should consider how whatever tooling we make for setting this password interacts with FDE. A user with high security requirements might use BIOS password, bootloader password, FDE passphrase, and a user account password, preferably all different. Most users with moderate security requirements will get away with just FDE though, and those with lower requirements can use a BIOS + bootloader password and avoid the overhead and potential data loss risk of FDE. Do we want our tool to tell the user “You’re using FDE, you probably don’t need a bootloader password”? If so, should we make some brief in-tool documentation that explains the threat models each configuration might be used to defend against?
How to set a bootloader password has been documented thanks to @nurmagoz.
If we had a simple script to automate these simple but non-trivial steps, that would be good progress.
Could that be upstreamed somewhere?
That’s for sure.
(Completely separate things.)
Alright.
Probably yes.
Step 1: Writing good documention explaining all of what we discussed in the wiki on Protection against Physical Attacks.
Step 2: This might be quite difficult to get the usability design right. Perhaps this should be discussed with calamares for wider input?
Hmm, I hadn’t thought about this being a Calamares feature request, though I guess that makes sense now that you mention it. I see there’s already an open report that you’ve interacted with at Allow Calamares to set GRUB password · Issue #2137 · calamares/calamares · GitHub.
Then again, do we want it in Calamares for Kicksecure? We’d be introducing more system state changing bits into the installer, which I know is something we’ve wanted to avoid in the past. It might be better to have a custom tool within the OS that the user can use to set or change the password. Such a tool would be usable in preinstalled VMs as well as newly installed systems.
If we were to use the custom tool solution, I don’t think this is something we could easily upstream somewhere, though it may be worth looking for existing tools that do this. If we want the installer-based solution, then naturally Calamares would be the best place to upstream it.
I forgot about it. Thanks for reminding me.
However, that ticket, while confusing, might be about grub disk encryption password prompt as opposed to grub boot menu authentication prompt.
Right.
That would be good.
From some brief web searches, it looks like Red Hat and Fedora both have a tool called grub2-setpassword (or grub2-set-password) for this purpose, which is a command-line utility that is apparently specific to RHEL-like distros. Based on a simple apt-cache search grub | grep pass, it doesn’t look like anything similar exists for Debian. Thus I think we probably should be writing a tool for this ourselves.