Sometimes it's to artificially narrow the lane to slow traffic. That's what they did here.
But.. your original comment is just.. wrong?
This isn't a critical security flaw unless you have the worst partition scheme on your encrypted volumes imaginable.
The default LUKS partition scheme is vulnerable.
It's not even a process flaw at that point, just "possible".
There is a successful POC, it is a flaw.
you can compromise disks once encrypted because everything is happening in an in-memory boot process.
This is not just in-memory. This is modifying the unencrypted part of initramfs on disk. Powering off the machine does not remove the exploit.
You always "boot something that is unencrypted." You then "mount" the encrypted volumes and load the OS.
This is how people can put an SSH server (dropbear) in initramfs so they can unlock remotely.
The attack is to initramfs, not the encrypted layer.
The order'ish:
- Boot
- Initramfs loads, gives you the LUKS prompt
- Initramfs decrypts/mounts OS
- OS loads
The other poster mentioned it, but some things that may help:
- There is a phone-friendly web editor built in for editing Markdown
- You're able to see the history of changes, and a reason why they were made if one was provided
- You can link directly to a line or header in the markdown
- Others can make changes that you can then approve or reject
I'm confused.
Initramfs is unencrypted in /boot when using LUKS with RAID. It has to be, right?
The attacker uses a debug shell to modify the unencrypted boot, so the next time you boot and type your LUKS password, they can gain access.
This doesn't line up with your comment?
Everyone is waiting for this. There needs to be a party.
A fun conversation starter is always "So do you have an internal monologue?"
No thanks. I get some people agreed to this, but I'm going to continue to use .lan
, like so many others. If they ever register .lan
for public use, there will be a lot of people pissed off.
IMO, the only reason not to assign a top-level domain in the RFC is so that some company can make money on it. The authors were from Cisco and Nominum, a DNS company purchased by Akamai, but that doesnt appear to be the reason why. .home
and .homenet
were proposed, but this is from the mailing list:
- we cannot be sure that using .home is consistent with the existing (ab)use
- ICANN is in receipt of about a dozen applications for ".home", and some of those applicants no doubt have deeper pockets than the IETF does should they decide to litigate
https://mailarchive.ietf.org/arch/msg/homenet/PWl6CANKKAeeMs1kgBP5YPtiCWg/
So, corporate fear.
I just use openssl"s built in management. I have scripts that set it up and generate a .lan
domain, and instructions for adding it to clients. I could make a repo and writeup if you would like?
As the other commenter pointed out, .lan
is not officially sanctioned for local use, but it is not used publicly and is a common choice. However you could use whatever you want.
I use a domain, but for homelab I eventually switched to my own internal CA.
Instead of having to do service.domain.tld
it's nice to do service.lan
.
Yea no clue what this is. No context, can't reqd what was attached because it's an image. Waste of a post.
I have the same box fan