<infinisil>
gchristensen fpletz (domenkozar): Sent an encrypted mail to you :D, for verification my key is 0x422E9EDAE0157170, fingerprint 6C2B 55D4 4E04 8266 6B7D DA1A 422E 9EDA E015 7170
<infinisil>
I'm also using WKD for infinisil.com, so the key should be found automatically for my mail
<infinisil>
I think that's what it's supposed to do anyways
<fpletz>
infinisil: thanks! but I think this is actually common to all linux distributions
<fpletz>
did I understand you correctly that is essentially like adding shell=/bin/bash to the kernel commandline?
<fpletz>
(on other distributions of course :))
<fpletz>
ah, init=/bin/bash of course
<infinisil>
Oh hehe
<infinisil>
init=/bin/sh
<infinisil>
Okay so I guess it's not a "problem" after all
<tilpner_>
That's nothing new, set boot.loader.systemd-boot.editor = false;
<tilpner_>
grub probably has an equivalent
<infinisil>
Why shouldn't this be true by default?
<tilpner_>
Because it's useful while debugging boot problems
<infinisil>
Hm yeah I did just use that to rescue a failed vps installation
<tilpner_>
With an unencrypted disk, setting that to true doesn't do much to protect your installation
<tilpner_>
Especially if you are virtual machine on malicious hardware
<tilpner_>
*are a
<infinisil>
Oh, I meant false by default earlier
<tilpner_>
Yeah, I assumed so
tilpner_ is now known as tilpner
<infinisil>
Hmm, okay so in the mail I mentioned how boot.debug1mounts can be used to have an interactive shell start. I guess if you have that parameter set, disallowing boot parameter editing doesn't protect you still
<infinisil>
But that's the cost to using boot.debug1mounts I suppose
<infinisil>
Using disk encryption would protect you though
<fpletz>
if you assume the hardware or the hypervisor is malicious or compromised, full disk encryption doesn't really help because the keys are in memory and can be extracted easily
<infinisil>
"By default, the boot loader interface is accessible to anyone with physical access to the console: anyone can select and edit any menu entry, and anyone can get direct access to a GRUB shell prompt. For most systems, this is reasonable since anyone with direct physical access has a variety of other ways to gain full access, and requiring authentication at the boot loader level would only
<infinisil>
serve to make it difficult to recover broken systems. "
<fpletz>
yeah, if you don't input your passphrase :) but also note that the initrd could've been modified to exfiltrate the passphrase without you noticing
<infinisil>
True dat..
<infinisil>
I guess an optimal system setup should have only the user partition encrypted, and it being locked automatically again when logging out
<tilpner>
When I had a Hetzner server, I used disk encryption to prevent sensitive data to end up in the wrong hands after disk replacement and sloppy disposal
<tilpner>
But there's no good way to defend against a malicious provider, and you should switch/not use them if you believe you need to defend against them
<tilpner>
*from ending up in
<infinisil>
Although, what if you trust them, but you don't know what will happen to them in the future
<infinisil>
(and that's kind of the case with all providers)
<fpletz>
yup, that's also the reason I have some physical hetzner servers with full disk encryption for some stuff (still not perfect but better than a hypervisor :))
<tilpner>
infinisil: How would this help with that?
<infinisil>
Hehe, make the server and your local machine send heartbeats. When no heartbeats are received anymore, the server shuts down, unloading all keys
<infinisil>
This way the provider can't just disconnect the machine and extract everything
<tilpner>
Why would they need to shut your VM down for that?
<tilpner>
I haven't used it, but live migration appears to be a thing
<infinisil>
Well if you use full disk encryption
<infinisil>
Oh damn
<fpletz>
yeah, the memory can be dumped and there are tools to find luks keys in memory dumps :>
<infinisil>
I guess there's no perfect defense
<fpletz>
for physical servers, they can freeze the memory chips so that they keep their state a while longer and just yank them out and dump them
<fpletz>
unfortunately, yeah :(
<infinisil>
If somebody really wants to be sure their data is secure they should probably run their own servers in their basement
<infinisil>
fpletz: Glad to know that sending encrypted emails works though :)
zarel_ has joined #nixos-security
zarel has quit [Ping timeout: 268 seconds]
__Sander__ has quit [Quit: Konversation terminated!]
hmpffff has quit [Quit: nchrrrr…]
iz16 has joined #nixos-security
iz16_izmntuk has quit [Ping timeout: 240 seconds]
<qyliss>
infinisil: one thing you might want to look into is Heads
<qyliss>
Which is a BIOS replacement that proves your firmware/initrd/kernel hasn't been tampered with before you enter your decryption password
<qyliss>
Very annoying to use with NixOS though. I'd like to make that better.
<infinisil>
qyliss: Neat, what's annoying with it?
<qyliss>
It implements a parser for a small subset of grub config files
<qyliss>
NixOS's are too complex
<qyliss>
So you have to trick it
<qyliss>
It can read extlinux config files too, but to get that work I had to ln -s /boot/extlinux/extlinux.conf /boot/extlinux/grub.cfg
<qyliss>
Additionally, you have to gpg sign your kernel and initrd every time they change, and store that signature in /boot