Tails, the Security-Focused OS, Adds Support For Secure Boot (zdnet.com) 20
Tail OS, an operating system optimized for privacy and anonymity, has released version 4.5 this week, the first version that supports a crucial security feature named UEFI Secure Boot. From a report: Secure Boot works by using cryptographic signatures to verify that firmware files loaded during a computer's boot-up process are authentic and have not been tampered. If any of the firmware checks fail, Secure Boot has the authority to stop the boot process, preventing the operating system from launching. The feature has been available as part of the UEFI specification for almost two decades but is rarely used. The reason is because not all firmware vendors cryptographically sign their files, leaving the door open to verification errors that -- when Secure Boot is enabled -- block many operation systems from launching.
I call Heads instead (Score:3)
Regardless of what new features they add to Tails, it still uses systemd so I'll stay with Heads instead: https://distrowatch.com/table.... [distrowatch.com]
Re:I call Heads instead (Score:4, Funny)
Re: (Score:2)
Tails and secure boot? (Score:2)
Why does Miles Prower need secure boot support?
Living in Venezuela I need tails (Score:4, Interesting)
Living in a country where the prevailing goverment censors many disenting websites (along with porn, which makes a good excuse), and tracks many of their citizens, TAILs is up-to-date and always in my toolbox.
I am not a politicaly important people, so I do not think I am being trakced. And, for the time being, a VPN is more than enough to access censored sites.
Having said that, every time TAILS is updated, I download it, then fire it up to remind myself how to use it. After all, if/when the goverment imposes a crackdown that actually requires TAILS it will be too late to downloadit and search the web on instructions on how to set it up and use it... so
Thank You very much TAILS.
Wait, what? (Score:2)
If it's security focussed why is it adding that only now? What else is it left out?
Re: (Score:2)
Functionality...
Re: (Score:2)
It is a stupid headline. They aren't 'security focused' at all. If you look at their 'security' page, all it says is they are based on Debian, and Debian says they take security seriously, so therefore we are secure. What they claim to be is privacy and anonymity focused.
Re: (Score:3)
Tails prevents tampering with the operating system itself. But the boot process can still be compromised.
So, ideally, a computer with a Verified Boot process [gitbooks.io] is required. That is not the same as 'secure boot' and is best achieved with an
Microsoft's involvement (Score:2)
Using an operating system in UEFI Secure Boot mode requires first adding the operating system's bootloader's signing key to the PC's UEFI configuration's keyring. Many UEFI configuration interfaces don't make this straightforward. Furthermore, at least in the Windows 8 era, Microsoft refused to license Windows for distribution on ARM devices that offered any sort of secure boot configuration interface at all. (I don't know whether this policy, originally intended for devices that shipped with Windows RT, co
UEFI Secure Boot is manufacturer monopolism... (Score:3, Interesting)
Yes, UEFI introduces some things BIOS never had. However, UEFI also introduced attack vectors. Now the [formerly BIOS]UEFI is being interpreted and executed prior to full boot. To protect against this, back in 2007 (not 20 years ago as TOA says but good enough) Secure Boot was created so that the interpreted and executed code would be AUTHENTICATED.
Authentication is a complex process. It involves a trust model (some use chain, some use onion, etc.) The UEFI SB model is flawed in that originally it was biased to MS+Intel and Linux/Mac were told to stay out. Then that changed. In the process it became clear SB is really about "Whom do you trust TODAY" and then that gets BAKED INTO HARDWARE FOR LIFE.
So yes, I did buy a Dell 2in1 PC. I guess I trust whom Dell trusted in 2018. I did get a Dell XPS. I guess I trust whom Dell trusted in 2019.
Sometime down the road I may find they trust Huawei. I may also find that Huawei are the good guys but someone else is the bad guy.
Either way with Secure Boot unless you're willing to undergo EXTREME MENTAL PAIN you have a hard time changing those keys.
Some of those keys you can't change (Thanks, MS). Some you can only add to (Thanks, Intel). Some you can't add. (Thanks US).
I don't know who the bad guys will be in the future, but if I can't edit the keys myself then my "secure boot" is a toy for manufacturer monopolism.
Ehud
Re: (Score:2)
If it is possible for you to edit the keys, then it follows that it must also be possible for others to edit the keys.
How do you prove that has not happened? Even an audit trail can be faked.
Re: (Score:2)
No, it does not follow that it is possible for others to edit the keys. Here is how we deal with it: when a new system comes in, the system is booted to the UEFI setup screens and the secure boot keys are cleared. This requires physical access. Then, we boot a Linux image and set the various secure boot keys using the 'efi-updatevar' command. Then, the Platform Key (PK) is set. The PK is a key that we generate and control. The system is rebooted and secure boot is enabled.
If there is a need to change the
Others can boot to UEFI (Score:2)
If it is possible for you to edit the keys, then it follows that it must also be possible for others to edit the keys.
when a new system comes in, the system is booted to the UEFI setup screens and the secure boot keys are cleared.
If it is possible for you to boot to the UEFI set up screens and clear the secure boot keys, then it follows that it must also be possible for others to boot to the UEFI set up screens and clear the secure boot keys.
Re: (Score:2)
Yeah, it you allow physical access then that can happen. If you allow physical access ANYTHING can happen, including installing compromised hardware. That is not some kind of hole in secure boot or UEFI.
Security and Systemd? (Score:2)
Are they kidding? The systemd developers don't know if it's secure because it's so over-complicated; why would anyone trust it?