
Safeboot: Booting Linux Safely - thudson
https://safeboot.dev/
======
balnaphone
I really like the philosophical approach here, even if it's too finicky to put
in practice today. I'm really sick of everything being made "secure", when in
fact the "security" is for someone other than the legitimate user of the
thing. Phones, laptops, physical security systems, cars, the list goes on.

There was a post here yesterday
([https://news.ycombinator.com/item?id=23149771](https://news.ycombinator.com/item?id=23149771))
about the (in)security of Linux, but the primary purpose of an OS is utility,
not merely security. The leadership of the Linux project made very smart
analyses of what priorities come first. Despite there being billions of
insecure old devices scattered about, running old kernels, I think the kernel
authors made the right call.

The problem rests with the manufacturers who abandoned support for those
devices _and_ left no escape route for users to update the kernels themselves.
Most disgusting are these phone and car manufacturers, and apps, which have
enabled wholesale spying on users for many years now. These devices are
literal bugs, reporting realtime locations, conversations, and who knows what
else to Big Brother.

Its a pleasure to see that some people still care enough to make the world a
better place, in a way I can understand.

~~~
CharlesW
> _I 'm really sick of everything being made "secure", when in fact the
> "security" is for someone other than the legitimate user of the thing._

It's less binary than that for me. Yes, the same technologies that keep _my_
data secure also act as a buttress against jailbreaking. But people who _want_
to jailbreak can simply choose less-secure devices, while I would personally
not trade that security for greater hackability. There are other, lower-risk
devices than phones and cars that I can use for that.

~~~
balnaphone
Apparently your threat model doesn't include governments and large
corporations, who have done more enumerable harm (e.g. through the military-
industrial-information complex) to people than small-time crooks ever have.
Sometimes it seems more people want to live in prison (or a gilded cage), than
in regular civilian life with all its attendant dangerous freedoms.

The point of the OP is that users can and deserve to have the reliability that
cryptographically-secure boot systems provide, without the Big Brother
backdoor.

~~~
CharlesW
I appreciate the conversation.

> _Apparently your threat model doesn 't include governments and large
> corporations…_

It's a consideration for sure, and it's why I use Apple devices instead of
Google-powered ones, don't use Facebook, use DuckDuckGo as my primary search
engine, etc.

I'm not worried about Apple selling my information (for now, given their
current business model) but my network provider is absolutely doing this
regardless of device. Given that, what actionable recommendation is even
possible?

~~~
balnaphone
It's a tough one, for sure.

Personally, I'm looking forward to a pinephone. I'm moving towards
asynchronous communications, and leaving my phone at home, or in a "faraday
pouch" (made of [0]) on airplane mode.

Networking is done through an elastic ip vpn that forwards to a known host, so
web sites that I want to use, but I don't want to trigger the captchas and 3FA
stuff, see the same user-agent and IP address. I also have many "disposable"
phones, that I use on projects that require Google Hangouts or WeChat.
Recently I had to upgrade my daily driver phone, and I haven't installed
Lineage yet. It's a slog, so I can totally understand why people would simply
accept what's readily on offer.

At a basic level, my thinking is that "is this better for me?". That is, how
are these capabilities[1] going to be used, in my favour, or against me? Since
I have previously been dragged into a large investigation (regarding someone
else operating under a false identity), and have had to get various clearances
from various governments to work on projects (which is more common than I
would naively think), the approach that I take is to appear unremarkable.

In the past, when leaving countries that require exit visas (like China,
Israel), I was shocked at how much information they had on me, and revealed in
the course of the exit interview. But I have to assume that Anglo countries,
if anything, have more advanced technical means at their disposal, but decline
to use them unless the target is juicy enough. So the reasonable approach is
to do my best to make my pattern "normal" and "unappealing" \-- maximizing my
benefit from these tools, and minimizing the risks of false associations and
accusations.

[0]
[https://www.sparkfun.com/products/retired/10056](https://www.sparkfun.com/products/retired/10056)

[1] [https://www.theverge.com/2013/8/1/4580718/fbi-can-
remotely-a...](https://www.theverge.com/2013/8/1/4580718/fbi-can-remotely-
activate-android-and-laptop-microphones-reports-wsj)

------
dathinab
Slightly unrelated:

I currently have a custom platform key, packet everything I need for booting
into a single image (signed with the custom platform key) and everything else
is in a fully encrypted partition (lvm2 on dmcrypt). "Decryption key" is
inserted via keyboard on boot, which is not to everyone's liking but is what I
want.

It's not really hard to setup (on arch Linux) and works like a charm. ;-)

Through the drawback is that the initRamFs is only protected by the
signature/secure boot but not encrypted and combining it with some other boot
related setup can be less straight forward then under a "boring" setup.

I.e. some of the thinks this project promises are already possible now, just
not streamlined. Which is why it's nice to have such a project.

~~~
thudson
That was exactly my motivation: there are tons of guides for setting up UEFI
SecureBoot platform keys, yubikey tokens, TPM disk encryption, dmverity, etc,
but all of them seemed to involve "type hundreds of commands with no mistakes
and hope that your system still boots afterwards". It felt to me that each
program represented a low-level library function that needed to be linked into
a high-level tool to handle the common cases for most users.

Regarding /boot being in the clear -- the initramfs and kernel shouldn't
contain any secrets, so having them unencrypted isn't a big drawback. Signed
is much more important so that an adversary with write access to the disk
can't swap out the kernel.

One advantage to using the TPM for unsealing the disk encryption key is that
it helps protect against attacks that re-write the firmware. If an adversary
can reflash the platform key (via either a local SPI flash programmer or some
code execution that gives them write access to the NVRAM region of the flash),
then you can't tell that the PK has been changed and that the kernel to which
you are inputting the password is no longer trustworthy. Since the secret is
sealed with (among other things) the hash of the UEFI SecureBoot
configuration, the TPM will not unseal it if the PK, KEK or db are changed.

If you want to take it to another level, TPM TOTP can be used to validate that
the password dialog is even valid before you type in the password. I think we
can integrate that fairly easily into the initramfs for the next version of
safeboot.

~~~
ohazi
There's a way to encrypt the boot partition and have GRUB ask you for the boot
partition key, but you're limited to LUKS1, and the decryption process is slow
as molasses, since it's implemented inefficiency directly in the GRUB code,
because the Kernel's faster code isn't loaded yet. It's also probably full of
side channel leaks. Signing the kernel and ramdisk is probably the better
option...

------
greendave
> fTPM tampering is out of scope since the ME is the root of all trust in the
> system

I'm wondering about this assumption. Hasn't the ME previously been shown to be
fairly straightforward to exploit?

~~~
dathinab
I think they refer more to the "technical" term "root of trust" then to
weather or not persons trust it/it has had security vulnerabilities.

------
seanhunter
If you're interested in this kind of thing, Invisible Things Lab are really
worth checking out [https://theinvisiblethings.blogspot.com/2009/10/evil-maid-
go...](https://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-
truecrypt.html)

------
tenebrisalietum
So what about this:

\- Copy GRUB, bootlines for your system, your kernel and initrd to a WORM
media like a bootable CD-ROM.

\- Boot using CD-ROM.

\- When boot completes, remove the CD-ROM.

Now you can't attack my boot kernel or boot process because I've just
physically separated it from the system and taken it with me. Even if it was
there, the media is read only so you can't modify it.

If I need to upgrade, I need to burn a new CD. CDs are cheap.

Using actual CDs would be impractical for many users, but a parallel could be
implemented on a system with micro-SD card readers supporting removeable media
and a physical read/write or connection switch. Which, if we're talking about
physical switches for camera and mic, why not boot files?

~~~
jaclaz
Hmmm.

This implies that you have set your boot order to CD-ROM first, so anyone can
- say - boot their own system on your machine from CD and either access your
data or make a dd-copy of your disk and look at it later.

You need also to password protect your BIOS so that first device in boot order
is hard disk and settings cannot be changed (without BIOS password).

Depending on the BIOS this change in booting order could be possible at boot
time (providing the password) or a reboot would be needed.

~~~
Avamander
> You need also to password protect your BIOS so that first device in boot
> order is hard disk and settings cannot be changed (without BIOS password).

You also have to make sure your BIOS can't be reset by removing the battery,
doesn't have some administrative bypass or even a reset jumper. I've even seen
a BIOS that reset to default boot settings when you remove all disks - and
then gleefully boots from any attached USB disk.

~~~
jaclaz
Yes, and additionally we will also need a machanically safe case, as - even if
the boot order is set to hard disk, it is not modifiable (without password)
and the BIOS resists removing power and battery, noone would prevent you to
detach the hard disk and either replace it with your own or more simply steal
the hard disk and have a look at its data without hurries.

Security is tough.

------
shawnz
Does anyone know if anything similar is possible with Windows? I am interested
in the idea of signing the bootloader with your own keys to prevent other
system images from being used on the system. It seems like such a system would
provide much better anti-theft guarantees than existing solutions like
CompuTrace/Lojack.

~~~
jimbobimbo
Isn't that what Bitlocker and Secure Boot do essentially?

[https://docs.microsoft.com/en-us/windows-
hardware/design/dev...](https://docs.microsoft.com/en-us/windows-
hardware/design/device-experiences/oem-secure-boot)

~~~
shawnz
In its typical configuration, Secure Boot can't provide any anti-theft
guarantees because an attacker could just replace the contents of the disk
with a new Windows installation and the workstation would be usable for them.

Secure Boot as it is configured by Windows only prevents malware from
inserting itself into the boot process, since all Windows installations use
the same signature. Bitlocker only prevents attackers from accessing the data
on the disk, not from using the workstation in general.

~~~
andrewnicolalde
Hmmm, is it theoretically possible to sign the Windows bootloader (?) with
your own custom keys to ensure that someone couldn't just fire up a stock
Windows image? Though I'm not sure what sort of management challenges that
would present if Microsoft ever decided to update their bootloader.

Looking at the Microsoft documentation, doing this with SecureBoot could be
pretty complicated: [https://docs.microsoft.com/en-us/windows-
hardware/drivers/br...](https://docs.microsoft.com/en-us/windows-
hardware/drivers/bringup/boot-and-uefi)

~~~
shawnz
I havent tested personally but this seems to suggest that you can't re-sign
the bootloader: [https://docs.microsoft.com/en-us/previous-
versions/windows/i...](https://docs.microsoft.com/en-us/previous-
versions/windows/it-
pro/windows-8.1-and-8/dn747883\(v=win.10\)?redirectedfrom=MSDN)

> "Windows boot components: BootMgr, WinLoad, Windows Kernel Startup. Windows
> boot components verify the signature on each component. Any non-trusted
> components will not be loaded and instead will trigger Secure Boot
> remediation."

Plus, you would need to add some kind of check to verify that it's actually
booting your image, or else the attacker could just copy your bootloader
files.

------
ghostpepper
I had originally hoped to enroll signing keys in the firmware of my X1 carbon
until I read this post[1] on reddit claiming it has the potential to brick the
laptop, and so far I haven't found an official statement from Lenovo claiming
otherwise.

[1]
[https://www.reddit.com/r/thinkpad/comments/epadb5/psa_dont_i...](https://www.reddit.com/r/thinkpad/comments/epadb5/psa_dont_install_custom_secure_boot_keys_on_x1/feig0js/)

------
pram
Sounds like what the T2 chip does on MacOS, which I also found interesting:

[https://duo.com/labs/research/secure-boot-in-the-era-of-
the-...](https://duo.com/labs/research/secure-boot-in-the-era-of-the-t2)

------
cachestash
Anyone interested in this might like keylime.dev - its open source remote boot
attestation platform.

------
temptemptemp111
If every Linux user would boycott AMD to release their source, then we could
have libreboot: [https://libreboot.org/amd-
libre.html](https://libreboot.org/amd-libre.html)

ME vs PSP isn't much of a choice. Of course POWER might be an option
eventually, but isn't for most of us currently.

~~~
Semaphor
Boycott AMD, and obviously Intel [0]. Doesn’t really leave a lot of options.

[0]
[https://libreboot.org/faq.html#intel](https://libreboot.org/faq.html#intel)

~~~
exrook
Well there is POWER[0], not that it's a very affordable choice, the cheapest
motherboard + cpu costing $1,732.07

[0][https://www.raptorcs.com/content/BK1B01/intro.html](https://www.raptorcs.com/content/BK1B01/intro.html)

~~~
yjftsjthsd-h
Is ARM an option? I know in practice _many_ ARM systems rely on blobs, but
it's not clear to me that that's universal.

~~~
q92z8oeif
There is nothing like "ARM" in the market.

There is CPU/SoC X by Y, built on top of a license from ARM.

So you would have to boycott N companies instead of just AMD & Intel :( And
even more so, since all their customers are EOM that are happy to sign NDAs.

~~~
CameronNemo
Decent blob scarce arm option:
[https://libre.computer/](https://libre.computer/)

