OpenBSD Finally Adds Guided Disk Encryption To Its Installer

[phoronix]

Phoronix: OpenBSD Finally Adds Guided Disk Encryption To Its Installer

Full disk encryption is quite important in today's computing environment while some operating systems still sadly don't provide an easy and streamlined manner of setting up an encrypted disk at install-time. Thankfully with the next release of OpenBSD, they are introducing a guided disk encryption option to their installer...

https://www.phoronix.com/news/OpenBSD-Guided-Disk-Encryption

[kpedersen]

Thats quite cool. OpenBSD's installer is the easiest and most streamlined I have ever seen and whilst local physical access to the machine generally means game over when it comes to security, an encrypted drive is useful as one small piece of the security puzzle.

[rene]

Wow 2023 and #t2sde Linux had better LVM2 and full disk encryption support in the installer? https://www.youtube.com/watch?v=6rzLbuwBvsU what a time to be alive!

[stormcrow]

Wow 2023 and #t2sde Linux had better LVM2 and full disk encryption support in the installer? https://www.youtube.com/watch?v=6rzLbuwBvsU what a time to be alive!

You know there's this amazing thing about free software... Anyone can step up and add a feature and ask the project to upstream it if they care for it. So where were you in the past several years that you supposedly cared about this feature? If you didn't care then, why do you care now? Your comment isn't constructive.

There's always going to be features X had in Y year that X has yet to implement. MacOS has had functional and useful HDR and HIDPI support for several years. Why doesn't Linux/X/Wayland + any given WM/DE not have it already? Gawd! There's many holes one can point out in the opposite direction. Why can you still intercept system and library calls on Linux as a user with a simple LD_LIBRARY_PATH definition by default on any given distribution? This is a major security hole (I'm not being entirely snarky. It's a major problem on Linux and Windows)! OpenBSD stopped allowing that for security purposes years ago! Yeah, I know it's a misfeature convenient for developers, but it also makes it trivial to compromise any dynamically linked executable - regularly done for good but especially for ill.

Side note on security: Windows has started allowing the practice of securely identifying any .DLLs an executable calls via signatures. It's not in widespread use, but the programs that utilize it can't be compromised by simply dropping a compromised .DLL in the executable's CWD any longer. Far as I know, there's no equivalent in Linux, and OpenBSD has restrictions on how you define the library search paths for ldconfig (like ignoring LD_LIBRARY_PATH), which Linux very pointedly does not. While it would have been nice to have a built-in method to set up FDE in OpenBSD's installer, it wasn't strictly necessary. It was relatively easy to do it from the CLI. Easier than trying to do it manually in Linux for certain.

[rene]

You know there's this amazing thing about free software... Anyone can step up and add a feature and ask the project to upstream it if they care for it. So where were you in the past several years that you supposedly cared about this feature? If you didn't care then, why do you care now? Your comment isn't constructive.

There's always going to be features X had in Y year that X has yet to implement. MacOS has had functional and useful HDR and HIDPI support for several years. Why doesn't Linux/X/Wayland + any given WM/DE not have it already? Gawd! There's many holes one can point out in the opposite direction. Why can you still intercept system and library calls on Linux as a user with a simple LD_LIBRARY_PATH definition by default on any given distribution? This is a major security hole (I'm not being entirely snarky. It's a major problem on Linux and Windows)! OpenBSD stopped allowing that for security purposes years ago! Yeah, I know it's a misfeature convenient for developers, but it also makes it trivial to compromise any dynamically linked executable - regularly done for good but especially for ill.

Side note on security: Windows has started allowing the practice of securely identifying any .DLLs an executable calls via signatures. It's not in widespread use, but the programs that utilize it can't be compromised by simply dropping a compromised .DLL in the executable's CWD any longer. Far as I know, there's no equivalent in Linux, and OpenBSD has restrictions on how you define the library search paths for ldconfig (like ignoring LD_LIBRARY_PATH), which Linux very pointedly does not. While it would have been nice to have a built-in method to set up FDE in OpenBSD's installer, it wasn't strictly necessary. It was relatively easy to do it from the CLI. Easier than trying to do it manually in Linux for certain.

yep, totally agree, that's why I'm here doing just that since 1998. <3 it!

[archkde]

Thats quite cool. OpenBSD's installer is the easiest and most streamlined I have ever seen and whilst local physical access to the machine generally means game over when it comes to security, an encrypted drive is useful as one small piece of the security puzzle.

Physical access to the machine only means game over if you're talking about an attacker tampering with the machine before returning it to you. Disk encryption (with a good passphrase, obviously) fully protects agains reading out data from a stolen laptop, for example.

[kylew77]

A God sent that is for sure!

[Barnacle]

Ah, OpenBSD, I have to agree with Linus about those guys.

It is pretty laughable that such a highly security focused BSD distro just now finally added a way to encrypt volumes during installation without dropping to a shell first to manually setup volumes. You would expect this idea to have been had and given high priority 20 years ago. This is what security engineers do. They are so singularly focused on "security theater" and pointless hypotheticals about the security of systems that have already been pwnd, that they never even consider how much pain they are causing for the people who supposed to develop and operate the thing they are securing.

[vladpetric]

You know there's this amazing thing about free software... Anyone can step up and add a feature and ask the project to upstream it if they care for it. So where were you in the past several years that you supposedly cared about this feature? If you didn't care then, why do you care now? Your comment isn't constructive.

I'm sorry but the reality is a bit different. Yes, anyone can code and contribute to whatever they please. Will that work actually be integrated/adopted/etc? In the vast majority of cases, the answer is no, and the criteria for integration/adoption is a lot more political than meritocratic.

[edgmnt]

Physical access to the machine only means game over if you're talking about an attacker tampering with the machine before returning it to you. Disk encryption (with a good passphrase, obviously) fully protects agains reading out data from a stolen laptop, for example.

Not entirely. I can safely recover data from a lost-and-found laptop, as long as encryption is authenticated. Some measures can even resist evil maid attacks to some extent or reduce losses.