=== JanC_ is now known as JanC [06:21] Good morning === frickler_ is now known as frickler [13:53] anyone think of a relatively painless way to have a server's LUKS-encrypted /boot/ content mirrored to another, TFTP, server, such that grub/kernel updates get replicated from the host to the remote so that this host can also do TFTP boot over the network - looking at using DRDB with onw half of the mirror on the localhost and the other on the TFTP server [13:54] I *think* localhost would have to do e.g. /dev/sda3 > LUKS > DRDB > ext4 > /boot/ rather than /dev/sda3 > LUKS >ext4 > /boot/ [14:26] TJ-: I'd probably use DRBD too but I don't know how easy it is to wire it into the boot logic [14:26] it doesn't need to be. it just needs to be there when the OS is running so any updates get written to the TFTP server as well [14:26] I'm almost finished configuring it now; will test shortly [14:26] TJ-: a possible alternative would be mdadm raid1 with a NBD disk as the mirror in (write-mostly) [14:28] the idea is for a low power Raspi battery-backed survives a site power outage. The APU2 gateway (x86) doesn't and is LUKS encrypted and would require serial console to GRUB to unlock /boot/ ... the aim is to set the system to try a PXE boot first, and if a PXE server responds, then it'll boot over the network and not need GRUB unlocking. [14:29] Raspi will monitor the state of the ethernet link between them and enable/disable dnsmasq when link goes down/up so it isn't always doing a TFTP boot [14:30] so a regular APU2 reboot, with the switch remaining powered, won't cause raspi to start dnsmasq [14:34] TJ-: this sounds awfully complicated and error-prone to me. Can you expand on the actual problem you're trying to solve here? [14:38] rbasak: unlocking grub at boot time on an unattended gateway [14:42] TJ-: what's your threat model? [14:45] no gateway [14:48] No - I mean why LUKS and also providing a method to bypass it? What's your threat model that requires LUKS but permits the bypass? [14:48] Because there might be other solutions, but without understanding your threat model that leads you to that, it's difficult to suggest anything. [14:51] literally, and figuratively. LUKS protects against there being no gateway (stolen). But device needs to be able to fully reboot since it is the gateway [14:53] So don't use LUKS then? I'm playing devil's advocate here. What's the difference? You're OK with providing automatic unlocking if something has not had a power outage? In that case, won't Mandos work? [14:53] Benefit is that it's less hackery. [14:54] LUKS is protecting sensitive info [14:54] no, LUKS is applied at the bootloader stage [14:55] LUKS is protecting nothing if you happily hand over everything needed to unlock it over the LAN! [14:56] If you consider "can get to the LAN" as "safe to unlock" under your threat model, then Mandos works without any less security. [14:56] TJ-: put the gateway on a UPS? ;) [14:57] leftyfb: unfortunately not practical in this scenario [14:58] Mandos doesn't protect against someone dropping a payload in the unencrypted /boot/ and collecting the data later. [14:59] Nor does PXE booting first, where anyone on the LAN can MITM whatever they want. [15:00] rbasak: but we'll know if there is any other device on the LAN, that isn't a problem. [15:02] TJ-: that's a brave assumption. [15:03] A switch with some MAC filtering will bypass that. [16:15] seems that drbd cannot handle link-local addresses, despite recommending not to route and only connect on a local segment! [16:19] rbasak: these things are outside, on top of very tall telegraph poles. [16:43] strange, drbd Changelog says for 8.3 Improved IPv6: link local addresses. Kernel has 8.4.11 [18:24] Turns out there's a bug in drbd-utils - cannot handle "fe80::" style addresses - have to expand the :: fully dso "fe80:0:0:0:..."