[HN Gopher] Safeboot: Booting Linux Safely
___________________________________________________________________
Safeboot: Booting Linux Safely
Author : thudson
Score : 115 points
Date : 2020-05-12 13:48 UTC (5 hours ago)
(HTM) web link (safeboot.dev)
(TXT) w3m dump (safeboot.dev)
| ghostpepper wrote:
| 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...
| tenebrisalietum wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| dathinab wrote:
| 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.
| jstanley wrote:
| What's your defence against an attacker with a few hours of
| physical access meddling with whatever comes _before_ you
| typing the decryption key, such that you 're actually typing
| your key into a program controlled by them, which then decrypts
| your filesystem image, inserts its own malicious code into some
| irrelevant kernel module, then boots the system as normal?
| thudson wrote:
| 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 wrote:
| 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...
| andrewnicolalde wrote:
| What's the disadvantage of not encrypting your initramfs if
| it's protected by a signature?
| greendave wrote:
| > 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 wrote:
| 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.
| shawnz wrote:
| ME has had exploits, but it has also had patches.
| shawnz wrote:
| 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 wrote:
| Isn't that what Bitlocker and Secure Boot do essentially?
|
| https://docs.microsoft.com/en-us/windows-hardware/design/dev...
| shawnz wrote:
| 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.
| aesh2Xa1 wrote:
| You can usually lock the whole system with a boot password.
| In the case where the attacker replaces the whole disk, or
| whole disk image with another Windows image, you can also
| add your own keys and sign the image or individual boot
| files.
| andrewnicolalde wrote:
| 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...
| shawnz wrote:
| 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...
|
| > "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.
| seanhunter wrote:
| 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...
| temptemptemp111 wrote:
| If every Linux user would boycott AMD to release their source,
| then we could have libreboot: 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.
| dathinab wrote:
| But if they release everything libreboot want's wouldn't that
| potentially undermine DRM (e.g. webdrm pluging as used by
| netflix)?
|
| I mean I'm not a fan of DRM but then undermining it might cause
| browsers on Ryzen to no longer be able to run Netflix and
| similar.
|
| While I guess many people on this site wouldn't care too much
| it's not profitable for AMD.
|
| But then there should be a way to have both. The case which
| don't need/want DRM and can have a complete libre system and
| the case which needs DRM for whatever reason and sadly can't go
| libre.
| dmos62 wrote:
| Or, instead of boycotting, work towards sensible laws for
| obliging software/hardware providers to provide sources.
| [deleted]
| Semaphor wrote:
| Boycott AMD, and obviously Intel [0]. Doesn't really leave a
| lot of options.
|
| [0] https://libreboot.org/faq.html#intel
| exrook wrote:
| 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
| yjftsjthsd-h wrote:
| 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 wrote:
| 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.
| freedomben wrote:
| It looks like that stuff was hot 3 years ago. Is there a newer
| (more likely to pay off) push? I'd happily tell AMD that I'm in
| the market for an expensive new system and I'd instantly go
| with Ryzen if it were open. As it stands now I'm leaning Intel
| because it's the devil I know.
| yjftsjthsd-h wrote:
| I don't understand. Intel has ME, AMD has PSP, neither makes
| any particular effort to support libreboot (although I'm
| pretty sure coreboot can work with both if the manufacturer
| wants, because Chromebooks do that). Unless you believe that
| Intel is _more_ open, why would you prefer it? It appears to
| me that they 're equally security-unfriendly, but with AMD at
| least winning on price and performance.
| balnaphone wrote:
| 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) 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.
___________________________________________________________________
(page generated 2020-05-12 19:00 UTC)