• 0 Posts
  • 8 Comments
Joined 2 years ago
cake
Cake day: June 15th, 2023

help-circle

  • given that Secure Boot prevents any modification of your computer’s boot chain

    Secure Boot does no such thing. All it does it require that everything in the boot chain is signed by a trusted cert.

    Binding TPM PCR7 to FDE (or more brittle options like 0+2+4) is really what protects against boot chain modifications but that’s another topic.

    Disabling SB to install the distro, then re-enabling it once installed with either maintainer-signed shim or self-signed UKI/bootloader is perfectly fine.


  • You need both FDE and Secure Boot, ideally with FDE using a TPM with PIN and PCR 7+15=0. FDE without SB can be trivially boot-kitted and obviously SB without FDE is mostly pointless. Maybe for a server/desktop behind locked doors you don’t worry as much, but for a laptop you absolutely should. Also it’s really easy in Arch to resign the UKI with sbctl via a pacman hook whenever the kernel is updated so there’s no good reason not to use it.

    If you’re relying on a LUKS password only, it can be brute-forced. To protect against that you need a decently long password which is annoying to type every boot. A short TPM PIN sealed by SB protecting LUKS is both more convent and more secure.

    Finally, if an attacker or malware gets root, FDE isn’t protecting you either.


  • Yeah this is an issue but not a big one. Most distro’s installation media don’t use shim so you have to disable SB during install anyway.

    And installing the 2023 KEK and db certs can be done via firmware without much trouble or you can use sbctl in setup mode which I believe has both the 2011 and 2023 keys.

    If you dual boot Windows you’ll want to update it to the new bootmgr signed with the 2023 keys and add the 2011 certs to dbx to protect against BlackLotus or let Windows do it via patches+regfixes.

    Also know that any changes to PK, KEK, dB, or dbx will change the PCR 7 measurement so handle that accordingly if you use TPM unlock for FDE.




  • The only thing missing is a good backup.

    If you are storing anything important – especially Immich and Vaultwarden data – you should have a good offsite protection strategy. And even the HASS config should be backed up with versioning because rebuilding from scratch could be painful once you get deep into it.

    I’ll let others chime in on possible good backup options because I use Veeam and Azure, which really isn’t in the spirit of this community, and I’d be interested in good open source options myself.

    Also, RAID (mirroring) is NOT a backup.


  • The easiest way that doesn’t affect the main network would be to use a travel router. Its WAN IP would be the private IP it gets from the main network (over wireless since that’s your only option). And it would NAT your network onto that IP and then you can do whatever you want on your network.

    I’m not sure if that Mikrotik router will do this but it might. You basically need something that can connect to an SSID and use that interface as its WAN interface. The wireless factor here is really limiting your choices. If you had a wired uplink to the main network you could use any router/gateway/firewall you wanted. You could also use an AP in bridge mode to connect to the main network’s SSID and wire it to the WAN port of any router of your choice.

    You don’t really need to use VLANs to separate your network from the main network unless you want to share any of the same layer 2 segments (basically wired Ethernet) while keeping it isolated. But it doesn’t really sound like that applies in your scenario. Of course using VLANs within your network would still make sense if that applies (for example, to separate your server traffic from your IoT traffic).