| === JanC_ is now known as JanC | ||
| lordievader | Good morning | 06:21 |
|---|---|---|
| === frickler_ is now known as frickler | ||
| TJ- | 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:53 |
| TJ- | I *think* localhost would have to do e.g. /dev/sda3 > LUKS > DRDB > ext4 > /boot/ rather than /dev/sda3 > LUKS >ext4 > /boot/ | 13:54 |
| sdeziel | 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 |
| TJ- | 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 |
| TJ- | I'm almost finished configuring it now; will test shortly | 14:26 |
| sdeziel | TJ-: a possible alternative would be mdadm raid1 with a NBD disk as the mirror in (write-mostly) | 14:26 |
| TJ- | 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:28 |
| TJ- | 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:29 |
| TJ- | so a regular APU2 reboot, with the switch remaining powered, won't cause raspi to start dnsmasq | 14:30 |
| rbasak | TJ-: this sounds awfully complicated and error-prone to me. Can you expand on the actual problem you're trying to solve here? | 14:34 |
| TJ- | rbasak: unlocking grub at boot time on an unattended gateway | 14:38 |
| rbasak | TJ-: what's your threat model? | 14:42 |
| TJ- | no gateway | 14:45 |
| rbasak | 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 |
| rbasak | Because there might be other solutions, but without understanding your threat model that leads you to that, it's difficult to suggest anything. | 14:48 |
| TJ- | 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:51 |
| rbasak | 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 |
| rbasak | Benefit is that it's less hackery. | 14:53 |
| TJ- | LUKS is protecting sensitive info | 14:54 |
| TJ- | no, LUKS is applied at the bootloader stage | 14:54 |
| rbasak | LUKS is protecting nothing if you happily hand over everything needed to unlock it over the LAN! | 14:55 |
| rbasak | 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 |
| leftyfb | TJ-: put the gateway on a UPS? ;) | 14:56 |
| TJ- | leftyfb: unfortunately not practical in this scenario | 14:57 |
| TJ- | Mandos doesn't protect against someone dropping a payload in the unencrypted /boot/ and collecting the data later. | 14:58 |
| rbasak | Nor does PXE booting first, where anyone on the LAN can MITM whatever they want. | 14:59 |
| TJ- | rbasak: but we'll know if there is any other device on the LAN, that isn't a problem. | 15:00 |
| rbasak | TJ-: that's a brave assumption. | 15:02 |
| rbasak | A switch with some MAC filtering will bypass that. | 15:03 |
| TJ- | seems that drbd cannot handle link-local addresses, despite recommending not to route and only connect on a local segment! | 16:15 |
| TJ- | rbasak: these things are outside, on top of very tall telegraph poles. | 16:19 |
| TJ- | strange, drbd Changelog says for 8.3 Improved IPv6: link local addresses. Kernel has 8.4.11 | 16:43 |
| TJ- | Turns out there's a bug in drbd-utils - cannot handle "fe80::" style addresses - have to expand the :: fully dso "fe80:0:0:0:..." | 18:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!