Yes! This is awesome! OpenBSD's Installer was already superb, much better than those calamares installers on your typical manjaro or whatever distro. It was plain easy. Many friends of me didn't switch to openBSD because they didnt fully understand the partitioning system but wanted their disk encrypted (like any sane person should do). I hope this will convince some of them.
I wrote a couple of scripts meant to help me lock down a machine for colocation in this "BitLocker" type manner. And, as luck would have it, lol... I'll (again) shamelessly self-promote the Show HN I wrote just a short while ago:
Sure... but that presupposes Unix based desktop and server systems are obscure and that the hardware in question is new. In reality, neither is accurate.
A huge number of people and organizations run Unix based systems and TPM devices have been around for a pretty long time (at least by tech standards).
The world's exactly as big as I think it is, and I've been playing with OpenBSD since 2004 or so.
The point was projects like OpenBSD often don't have support for more recent hardware, and given OpenBSD is used much more as a router than a server, it's a very reasonable presupposition.
Lol, sorry... you're wrong. The question was posed as:
>there any support in OpenBSD, or indeed any Unix-based desktop/server operating system
That's a wide swath and TPM 1.2 was finalized in 2011, saying "of course" was perfectly fair. It's one thing to say that such a device, perhaps a specific revision from a specific manufacturer, might not be supported on a specific release of an even more specific distribution... but that wasn't the case.
Trolling and quibbling over a common colloquialism such as using the phrase "of course" is not constructive.
lol I'm not wrong, but this is so silly. What's not constructive is you really needing to have the last word. If you don't want to 'quibble', don't reply.
I'll just say this. Saying 'of course' that an obscure OSS OS (and yes, OBSD IS obscure, and anyone not being emotional should be able to admit that) having full hardware support is silly, when so many similar OS projects still don't have support for much hardware.
Besides, TPM is at version 2 now which was announced in 2014, so where is the OBSD support for TPM 2.0? Why does it not support it?
Saying 'of course' it supports it was indeed silly when it doesn't support the more recent spec which is still 9 years old and isn't backwards compatible...
Ok, congratulations... you're right. You can can have the last word instead. I must have said "OpenBSD fully supports every piece of hardware known to man" and missed it. I sincerely apologize for that. You, in no way, tried to put words into my mouth.
And here I thought I was merely stating that there is some Unix variant somewhere on this planet that supports a TPM, any TPM. I'm a boob; sincere apologies. You've made the world a much better place!
It is designed for the very typical corporate situation of "I don't trust my users". If you don't have admin rights on that machine, you can't get or bypass them easily by e.g. taking the drive out, imaging it, and reading that on another computer. The keys stored in the TPM are also available to the domain controller, not (easily) to the (non-admin) Windows user.
It protects against data being directly copied off the disk, or modified, by anyone who may have physical access to the machine, but who lacks credentials to log in.
Wouldn't that require that the complete boot chain is totally locked down and cryptographically secure?
If you can insert a usb-plug and boot from that you could unlock the disk with the help of the tpm, or interrupt grub and set init=/bin/bash.
Or since the scenario is that the attacker have physical access, maybe desolder the tpm chip and move it to another computer where they have control over how the machine boots.
I guess modern gaming consoles are locked down in such a way so that this makes sense, but I have never seen a general purpose computer secured like this.
Thanks for explaining, I guess the above was mostly my stream of consciousness ranting.
TPM chips are specifically designed so that what you're suggesting won't work.
Their PCR registers (Platform Configuration Registers) act as sort of tripwires so that the boot chain isn't "locked down" but "measured". Each step of the boot chain updates a register with it's own hash that's hashed with the prior step's hash. What a tangled web, huh?
That way, if you're sealing your data to the appropriate PCR registers, the data won't be able to be retrieved if any part of the boot is changed... e.g. usb device plugged in or kernel/grub parameters changed.
In addition, TPM chips are "married" to the computers they're plugged into. Once you remove a TPM and put it in a different computer it will reset itself.
I just did a fairly deep dive into all this getting a machine up and running for co-location. Coincidentally, I just posted a "Show HN" here...
> If you can insert a usb-plug and boot from that you could unlock the disk with the help of the tpm, or interrupt grub and set init=/bin/bash.
You can't easily do that as the platform control headers will be different to those set by Windows. You can't brute-force it as they have a realtime clock and lock after about 32 attempts, granting one more attempt for each ten minutes. Getting the bit-locker key from a discrete TPM v1.2 or v2.0 requires being a bus pirate [1]. Getting it from a "soft" TPM inside a CPU is likely much, much harder.
For me personally as a non-corporate use, I use it to encrypt my laptop and not require a password to need to decrypt.
This is deliberate as I protect my important stuff again with VeraCrypt.
The reason for the automatic login via TPM is have a windows guest account that automatically logs into a very restricted guest account (that can only use a locked down chrome and play movies from usb, nothing else) that can't be changed (not without resetting the bios or replacing/wiping the hdd).
Since the laptop is running prey, my hope is any thieves would be using it. Without an automatic login with a key obtained from TPM, I couldn't have the same setup.
Good question: Is OpenBSD more secure than a mainstream Linux distribution, notably Debian, in their default configurations?
The code is less, but there are fewer developers too. For example, basic support for disk encryption (an important security feature) has been added to the installer in 2023 in OpenBSD.
Perhaps people familiar with the software development process in both could chime in.
Yes and No. Both modern Linux and OpenBSD have their pros and cons. For example, security works better in the onion layers, which can increase complexity. With Linux, you get a modern stack such as Linux containers or ZFS if you want those excellent filesystem features. Are you using containers for development and deploying apps? Using Linux would simplify the process (of course, you can set Linux VM under OpenBSD and run Docker).
On the other hand, OpenBSD is a compact OS. Less code == fewer bugs (at least in theory). Some of their code, such as OpenSSH, is wildly used by Linux, Windows, and major IT vendors in their devices. OpenBSD devs do write reliable code. In short, use whatever gets your work done quickly, which also keeps you or your devs/users happy. That is all matter. Apart from that, it would be best if you took all other precautions to secure your OS, such as regularly applying patches, and firewalls, installing adblocker, not downloading unwanted stuff and clicking on the links, regardless of whether it is Win11, macOS, Debian/Ubuntu Linux, or OpenBSD.
> With Linux, you get a modern stack such as Linux containers or ZFS if you want those excellent filesystem features.
While might be more pre-oackaged containers available for linux, our OCI stack has nothing on BSD's Jails. ZFS was ported to linux from Solaris, and still runs better on the BSD's (at least in regards to license controversies, if not feature support or performance, which have mostly converged in OpenZFS). The linux-native option would be BTRFS (love them both :p).
OpenBSD does not support jails or ZFS. Those are FreeBSD features (although perhaps NetBSD supports some of them too?). I really like OpenBSD but I think it’s counterproductive to lump them together: they are very different.
Linux has a richer set of security features available than OpenBSD, in some areas.
One is the mandatory access control of SELinux, used extensively in Android (probably the most widely-used Linux distribution of them all). This has no OpenBSD equivalent, as far as I know.
Another is that the Linux kernel has some compiled-in exploit mitigations enabled that OpenBSD doesn't, such as automatic bounds checks on fixed-size array access (based on UBSan).
That's not true. There is pledge(2) and unveil(2) (just to start) and the whole point of them is to _make it usable_. Some Linux distros have a basic config for SELinux, but if you need to change it for anything, it's so difficult that most people just end up disabling it, thus making it less secure than a default OpenBSD install.
Besides this, it changes the perspective of who is the best person to configure the secure features. OpenBSD makes this a decision for the developer of the application, who should know better about it than a random sysadmin who most probably won't even open the source code to know better (this is the approach SELinux takes).
You can say that, but unveil(2) will hide whole portions of any file system from a application. I do not think selinux does that (correct?). For example, firefox can only access ~/.mozilla/firefox, ~/Downloads and that is it (IIRC). There may be other directories I forgot.
pledge(2) will hide system calls to prevent unintended processing.
But, for the application programmer, it may be a bit harder and you need to know what you are doing. One hopes the programmer knows what he is doing :)
IMHO, pledge(2) and unveil(2) is far easier to maintain than selinux, containers etc. But of course the programmer needs to code it. And not to mention, these calls are far more efficient than the multiple containers out there.
(edit) I also saw somewhere a person is tring to get pledge(2) and unveil(2) into Linux, but I forgot all the details.
Hiding filesystems is security via obscurity more than anything else, and probably won't hold up if someone has root.
Things like SELinux by contrast allow you to remove all access and power from the root account except for what it specifically needs, while allowing you to grant root capabilities to other accounts as needed.
>Hiding filesystems is security via obscurity more than anything else, and probably won't hold up if someone has root.
That statement indicates you do not fully understand pledge(2) and unveil(2).
For example, if you are running Firefox using the default settings as root on OpenBSD. Firefox will not be able to see anything outside of the directories allowed by unveil(2). So an errant JS will not be able to peruse "veiled" Directories. For instance, Firefox cannot see any data in ~/.ssh no matter what ID you are using.
OpenBSD’s heavy use of pledge, unveil, privilege separation, unprivileged processes, chroot, and strong memory protections do an excellent job of keeping attackers from gaining root.
It's absolutely possible. No idea about a proof of concept, but I don't even think it matters, honestly.
It's cute that the OS might play some tricks to hide them from you, but at the end of the day, that's all it is doing, is hiding. Security by obscurity.
You're just betting you hid them really really well and that no one will be able to find them. With zero preparation in the event someone does.
If you have root, you have access to the files, period. Someone determined enough could search, read and write to the disk directly, bypassing the filesystem.
unveil is defense in depth, but it shouldn't be treated as a final line of defense which too many obsd fans seem to want to do.
Please don't respond to a bad comment by breaking the site guidelines yourself. That only makes things worse.
Also, can you please not perpetuate flamewars on HN generally? It's not what this site is for, and destroys what it is for.
I've banned the other account and I'm not banning yours because as far as I can tell you didn't break the rules as badly and you haven't been making a habit of it—but if you'd please review https://news.ycombinator.com/newsguidelines.html and not do this kind of thing in the future, we'd appreciate it.
I'm not spouting crap at all, you just really have your head buried in the sand. YOu've drunk more of the OBSD koolaid then even mac zealots drink of the mac kooolaid.
I won't be replying again as I don't see how this is wroth my time when you can't even support anything you've said.
You haven't given an example of how you'd even open the raw device after you've been unveiled to /home/Zurrrrr/Downloads, and had your syscalls pledged (so, no mknod -- there's no pledge that allows it at all).
You haven't replied the first time to my questions with anything of substance, so what exactly do you mean by "replying again"?
> They aren’t (and do not) require any privleged system calls, whatsoever.
You're making a distinction about 'privileged' system calls, why, exactly? You really think something like Oracle won't require access to a ton of syscalls to work correctly?
> If you can actually exploit a system call, neither a MAC based approach or a pledge will help.
> System call filtering isn't a sandbox. It provides a clearly defined
mechanism for minimizing the exposed kernel surface. It is meant to be
a tool for sandbox developers to use. Beyond that, policy for logical
behavior and information flow should be managed with a combination of
other system hardening techniques and, potentially, an LSM of your
choosing
I've used it. I know what it does. For a while, I've even run a linux with a slightly patched version of it for some quirky needs of my own.
seccomp-bpf is a more fragile version of pledge; you need to keep changing your sandbox whenever you upgrade glibc, because there's no mechanism to keep syscall usage in sync between the kernel and userspace.
It was fine for my case, because I was implemeting my own direct system calls, and froze any external dependencies, but it's typically very fragile across system and dependency upgrades.
You need to get root in first place. Good luck trying to crack any pledged process running something outside it's allowed syscalls without being ABRT'd in zero time.
Yeah, it's not like OpenBSD hasn't had remote root issues before...
And this is exactly what I'm talking about. Putting more energy into hoping no one ever gets root rather than providing anything to protect against the scenario where it is obtained.
You are not wrong but also not right, it's something different.
For example FreeBSD has a MAC framework (a massive one btw) and also the "SELinux/SEBSD" framework on top of it (FLASK/TE), but you don't need to use it (not on Linux nor on FBSD).
OpenBSD has no MAC implementation, and with that no framework (SE*) on top of it, but has different/other way's to secure a system.
And TBH i have seen just 3 Customers until now who really develop highly secure/complicated policies (Two use MLS and one uses Brewer-Nash)
I think MAC should be used much more, but it's time intensive and hard to do it right, also to keep the policies clean and understandable need's LOTS of documentation and dedication.
What massive MAC framework does FreeBSD has? Last I heard SELinux was attempting to be ported (SEBSD) but that was never finished?
The 'different/other/ ways to secure the system are inferior since they offer no protection if root is compromised.
I don't think MAC is as hard to use as it was, there are so many policies and issues known this much later, but people still just disable it by default because they don't want to put in the time.
That's NOT what i said, the FreeBSD MAC implementation is big and pretty much feature complete, NOT SEBSD.
>The 'different/other/ ways to secure the system are inferior since they offer no protection if root is compromised.
There is no such thing as "inferior" but different approaches, from completely deleting root as a user to using Container/Jail/Zones, Sandbox's, VM's etc. MAC is one of just many methods and OpenBSD voted against it and went another route (and that is totally fine and understandable).
>I don't think MAC is as hard to use as it was
MAC is still very hard, you are talking about SELinux that is just one implementation called FLASK/TE.
Try to implement Brewer-Nash MAC-policy on a Fileserver and i will see you sweating ;)
But as you can see, there is you and me (in this thread) who understand what a MAC even is, and that on HN....that just tells you how many people really have even a understanding what it even is.
> That's NOT what i said, the FreeBSD MAC implementation is big and pretty much feature complete, NOT SEBSD.
It is what you said. I never said you claimed SEBSD.
You said FreeBSD has a massive MAC framework. I was asking which one, and the only one I know of is SEBSD, which is not at all massive.
You are saying now FreeBSD has its own MAC framework, but I've never heard of it. What is it called?
> There is no such thing as "inferior" but different approaches,
Well that's not true. A screen door vs a heavy deadbolted door is clearly an inferior approach, not just a different approach to security, and that analogy extends to OS security technologies.
MAC is the only system that can 100% protect against an attacker getting remote root.
> There is no such thing as "inferior" but different approaches,
I've been dealing with MAC for 20 years, so I don't find it hard at all, and if people are willing to put in the effort to learn it the reward is worth it. But this is a world where most people want to get home to watch their latest story instead of doing any kind of mental work, and admins are no different.
This is frustrating. I don't know why you are trying to explain things when the issue is you simply were not clear with your first comment, and then acted like I misquoted you.
> SEBSE is a Framework, MAC is an implementation, those are two different things on different levels.
This is incredibly wrong unless you are referring to something other than mandatory access controls when you say MAC.
MAC is a concept. SELinux AND SEBSD are implementations. And yes, you can say they are implementations of FLASK, or call them frameworks, but semantics aside none of that changes that SELinux and SEBSD are implementations of a concept.
Saying MAC is an implementation is just flat out wrong.
And for what it's worth, I was correct when I said it was SEBSD, even though it isn't called that anymore. That's what the project started off as before it was merged: http://www.trustedbsd.org/sebsd.html
> Yeah no you don't since you don't even know the difference of SELinux and the/a MAC implementation.
>Linux Security Modules (LSM) is a framework allowing the Linux kernel to support without bias a variety of computer security models. LSM is licensed under the terms of the GNU General Public License and is a standard part of the Linux kernel since Linux 2.6. AppArmor, SELinux, Smack, and TOMOYO Linux are the currently approved security modules in the official kernel.
I have no idea why you think linking that proves some kind of point, it only proves to me that as I said you are very much out of your depth in joining this conversation.
We've banned this account for breaking the site guidelines badly and repeatedly in this thread, and for ignoring our many requests to stop doing that.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
Since no one has specifically mentioned it yet.. OpenBSD has had the ability to do FDE from installer since FDE was added to OpenBSD (sometime prior to 2007).. This change makes it more convenient.
Yes, you are correct in the sense that you need to create a partition within which you build an encrypted 'device' before running the installer script. And then at the appropriate point in the installer dialogue you need to select the encrypted device as the target to install to. It is I agree only a few extra commands, but obviously one of the OpenBSD team thought it worth while to automate those few steps for 'common' cases.
Above is the section of the FAQ about full disk encryption for OpenBSD 7.2 which is the most recent release.
PS: I agree fully with a parent comment that the OpenBSD installer is superb. It is like working your way through a checklist. Nice and straight forward once you have read the FAQ first.
OpenBSD's default configuration has basically nothing running. Once you actually set it up for a use case, it isn't much better (you'll likely be running software you would on Linux that wasn't audited) and might even be worse given it lacks a lot of security features Linux has (meaning you have less control over how to lock down things in the case of a hack).
False. OpenBSD's daemons are patched, sandboxed and reviewed and lots of software it's compiled with secure CFLAGS and LDFLAGS among some tweaks for browsers with pledge and unveil.
It's not false. No significant services are running by default, and for it to do anything useful you have to install and/or enable whatever services you want.
It ships with many of the services you may want by default (httpd, relayd, bgpd, etc).
Major external packages are patched to improve security. For example, a compromised chrome or firefox can't observe any directory other than ~/Downloads; pledge and unveil take care of that.
Oh for sure, it can be somewhat useable for many simple cases. Many people, even most though will need to deviate from the default install. I mean, if someone is running httpd, a database might not be far behind, just for example.
The comment directly above yours was referring to the work that some of the OpenBSD packagers do when providing packages for installation on OpenBSD additional to the base, using pledge and unveil.
As a concrete example, Firefox can only load/save or download files to ~/Download by default.
Who cares, your point it's still wrong as you don't understand how much OpenBSD diverges from Linux and even FreeBSD and NetBSD on security and correctness.
No, I understand absolutely. I've been playing with OpenBSD for over 20 years.
My point is that OpenBSD wants to focus on trying to remove bugs as much as possible, and securing the system in case a bug is exploited is very much a secondary objective.
Pledge and unveil are nice, but insufficient compared to what SELinux can do, or similar systems. That's simply objectively true, regardless of if your bias towards OpenBSD will let you admit it or not. So no, my point isn't wrong, you're just possibly out of your depth in this convo.
OpenBSD provides NOTHING to protect against an attacker who gets remote root, it just really really really hopes they won't.
I don't know why you're acting like anyone actually uses SELinux the way you are describing it. It's notoriously a pain in the ass to configure any meaningful system-level protection from root accounts, to the degree that most deployments who bother at all only protect one or two directories. Even then SELinux is such a bolted-on mess that it's still subject to evil maid attacks and so forth.
And you're wrong about OpenBSD. I'm not going to get as angry about this as you appear to be, but I recommend you run "man 7 securelevel" on one of the OpenBSD systems you've been playing with for 20 years.
You're very wrong about SELinux and I assume haven't touched it in years. It's enabled by default in Fedora, other distros use it as well, and it really isn't at all that big a deal to learn and configure proportional to the benefit.
I'm not remotely wrong about OpenBSD, and that manpage doesn't contain anything that contradicts a point I've made.
I administer thousands of selinux boxes professionally. I, like the vast majority of Earth's population, remain steadfastly uninterested in Fedora's default behavior.
You claim that OpenBSD has no conpromised-root mitigation. I have provided evidence to back my counterclaim. I will assume your rejection of actual evidence indicates a disinterest in good-faith argument, so I won't bother pressing the point, except to mention that you may be more successful persuading people to support your case if you adopt a reality-based approach to argument instead of just making wild-ass assumptions about other people.
> OpenBSD provides NOTHING to protect against an attacker who gets remote root, it just really really really hopes they won't.
Alright, if we're talking about things that are objectively true, this is objectively false. They specifically go to great lengths to make it impossible to get root.
You did, actually; you said that OpenBSD just "really really really hopes" that an attacker won't get root, and I pointed out that that was nonsense and that they are in fact taking measures to ensure it.
Besides, by that logic, your systems are totally insecure because you're just really really really hoping the attacker doesn't get an unconfined process.
Saying OpenBSD 'really really really hopes' an attacker doesn't get root is still 100% correct. They are still prioritizing removing bugs ahead of time instead of providing stronger tools to prepare for a scenario where someone does exploit a bug they didn't get to.
> Besides, by that logic, your systems are totally insecure because you're just really really really hoping the attacker doesn't get an unconfined process.
Which is where things like SELinux come in, which is my whole point.....
> They are still prioritizing removing bugs ahead of time instead of providing stronger tools to prepare for a scenario where someone does exploit a bug they didn't get to.
They're absolutely dealing with that situation as well. So let's say for instance that the default OpenBSD httpd turns out to have some bug that allows an attacker to execute any arbitrary code of their choosing on the server. That's a problem, but it's hardly the end of the world. First, the server is using pledge+unveil, so it can't actually do all that much other than serving web pages. Second, even if the attacker can work within those restrictions, they're running as a completely unprivileged user, because OpenBSD is actually a great fan of defense in depth.
> Which is where things like SELinux come in, which is my whole point.....
If we're assuming an attacker can run things as root, then obviously we have to assume that they can run things in an unconfined context as well, at which point you've just basically added a second word for root and nothing helps.
Also, pledge would SIGABRT that's process under a milisecond upon trying a non-allowed syscall.
So, as I said, good luck trying to call something outside pledge. Being root? You wish if you can even run something alonside the process.
Because even the subprocesses from a pledged process are pledged too.
Jesus christ, once again, the point is it doesn't matter. There is nothing in place if someone does. Good security is preparing for different possibilities, not just hoping one never happens because it seems unlikely.
You're just proving what I said above 100% correct, that the OBSD approach is to just really hope that no one ever gets remote root.
Tell you what, getting root on a properly configured MAC system is 100% impossible, so I'll choose that over a system where the developers just really really hope something bad won't happen every day of the week.
I honestly can't even imagine putting all my faith in pledge and chroot like you do. It genuinely boggles my mind that you think this is a good approach.
The only way a program can interact with the system is through system calls. Can you explain why irreversibly taking away a program's permissions to do anything interesting, especially as root, is a bad approach?
> They're absolutely dealing with that situation as well.
That's why I said they were prioritizing. The very use of that word obviously means they are not just working on one thing....
Why do you keep arguing against strawmen?
I won't address your scenario because you chose one that is overly favorable to your point, it doesn't really show anything.
> If we're assuming an attacker can run things as root, then obviously we have to assume that they can run things in an unconfined context as well,
That's a really, really dumb assumption, because that kind of issue is addressed. It's an entirely different user from root that administers selinux policies....no reason at all to assume root can run unconfined when that's counter to the whole point of running SELinux....
These are really, really bad arguments you are making.
You're really just showing you have no clue what you are talking about lol. That seems to be true for most of the people in this thread defending OpenBSD, as you're not the first to make the point.
The reason it's wrong, the reason it's clear that you have no clue what you are talking about, is it's a basic design decision that it is not the root user that configures or removes policies. Root has no ability to do what you describe, and under SELinux is just another user.
But hey, keep spouting nonsense because your feelings are hurt because you have some weird attachment to an obscure OS.
If you believe that there's a way to become root, why don't you believe there's a way to become some other non-root user? Possibly by using the same exploit you'd use to get root, or possibly by using the permissions root has?
I'm not being smug or insulting when I ask this, but are you familiar with SELinux at all, or have you administered any systems?
> If you believe that there's a way to become root, why don't you believe there's a way to become some other non-root user?
SELinux maintains it's own set of users that map to unix user. SELinux users have their own roles and capabilities that are very granular. It's frequently configured to make root 'just another user' as much as possible, and remove any access root doesn't need.
So if you 'get root' on a properly configured SELinux system, you don't actually 'have root', you just have a user with a user id of 0 but no real access.
You can switch to whatever user administers SELinux policies, but you will only be switching in the unix sense, not the SELinux sense, so you won't actually be able to do anything.
To do what you are suggesting would require a kernel exploit, but even if you get root you won't have any access to run it.
What you suggest simply is not possible barring very specific vulnerabilities being found, which afaik, have not been.
I'm not being smug or insulting when I ask this, but are you familiar with pledge and unveil at all, or have you written any code?
Pledge and unveil maintains it's own set of system calls and allowed paths that a process may access. Pledge contexts have their own system call masks and capabilities that are very granular. It's hard coded to make root 'just another system call maker' and remove any access root doesn't need. The permissions are ratcheted down as the program initializes, so a process typically doesn't even have access to its own configuration, let alone anything important. Once httpd is started, it can't even start listening on a port -- no matter how much root it has.
So if you 'get root' on a properly pledged system, you don't actually 'have root', you just have a program with a user id of 0 but no real access to make system calls.
You can switch to whatever user you want, but you will only be switching in the unix sense, and not changing the allowed set of system calls and data accesses, so you won't actually be able to do anything.
To do what you are suggesting would require a kernel exploit, but even if you get root you won't have any access to run it.
What you suggest simply is not possible barring very specific vulnerabilities being found, which afaik, have not been.
Haha, so you can't even answer the question lol. Yeah, it's clear you have no clue about SELinux at all.
What is with you and putting so much effort just to argue out of loyalty and emotion when you don't even know the thing you are arguing against, aside from assumptions?
Pledge is a goddamn toy and it's hilarious you think otherwise. Pledge isn't going to do ANYTHING to protect, say, a complex database server or any number of third party programs that need all kinds of access, and require being able to make all types of syscalls.
You've parroted my own reply back at me, without bothering to comprehend it or realize that it doesn't apply at all in the way you've bastardized it and tried to force it to.
You clearly, CLEARLY have no clue at all what you are talking about, and are basically just the OBSD version of a linux zealot stereotype.
In short, you're a tool. You clearly need to have the last word due to your ego, so have at it, but I won't waste my time by humoring you further. It's genuinely a shame I can't block you and will still be notified of whatever noise you make next.
> Pledge is a goddamn toy and it's hilarious you think otherwise. Pledge isn't going to do ANYTHING to protect, say, a complex database server or any number of third party programs that need all kinds of access, and require being able to make all types of syscalls.
Here's a program that will run an arbitrary command under the same
restrictions as Chrome. Presumably, Chrome counts as a complex third
party program.
You keep insisting that if you can run pledged and unveiled code as root, you can break out. Let's get that part of the discussion out of the way first, and then I'll happily switch tracks to pledging oracle.
Though I'm not sure why you think it'd be much harder than pledging Chrome or Firefox.
Again, can you give an example of an jailbreak you're thinking of? So far, I don't even think you've given a clear explanation of your threat model. Once we have that, we can have a discussion about Oracle fits into it -- but until then, there's no substance.
What operations would you use to break out of the above sandbox? Once you give me that, I'll happily discuss the details.
You could do it by hand with bioctl since forever. You had to spawn a shell with !
from the installer, run the bioctl commands to assign a new device to get
encrypted and then on installing you would select that new device instead of your raw disk.
Thing is, they say “Read the FAQ” - and if you actually do read and follow the FAQ then you can do what you want 99% of the time.
For example, couldn’t access the internet using WiFi and wired Ethernet at the same time - spent hours fiddling about, trying to make both adapters ‘egress’ - couldn’t do it. Then … remembered the FAQ:
Networking -> Wireless -> Trunking a Wireless Adapter
Yes. And then when you ask why the X11 server is bundled by default, even on a headless install, that's not in the FAQ, and they get very defensive about it...
What I'm saying is: it's probably a great OS with great documentation, but the community isn't welcoming at all.
There are packages like image libraries, Java etc that rely on X11 libraries. The safe default is to have it around.
You can always choose to not install all X* packages. In fact, for a server oftentimes you don’t need more than the base package (you barely need a compiler either or games).
> New users are recommended to install all of them.
> Some libraries from xbase72.tgz, like freetype or fontconfig, can be used outside of X by programs that manipulate text or graphics. Such programs will usually need fonts, either from xfont72.tgz or font packages. For the sake of simplicity, the developers decided against maintaining a minimal xbase72.tgz set that would allow most non-X ports to run.
On a server, you need x11 clients and xauth, if you want to run x11 programs via ssh x11 forwarding.
> New users are recommended to install all of them.
That's kind of bullshit though. If someone has plenty of experience with *nix OSs then OBSD isn't that strange, and a 'new' user asking a reasonable question should not be greeting with attitude.
"They" don't have an "IRC". #openbsd on Freenode/Libera is an unofficial venue. The channel isn't endorsed by the project or the foundation. In some moments you run into friendly people, and in other moments you run into angry people. It's not an OpenBSD thing. As someone who has been a regular in #openbsd for some 20 years I will assure that it's mostly friendly and helpful.
So, a random person on #openbsd once said you to RTFM and you are still salty a few years after? My (also anecdotal) experience with the openbsd community is very positive, so here's that.
Some projects are just about belonging to some arcane group, not about creating something much useful... though of course the said group would disagree.
Disk encryption wasn't even part of the default install flow before. You had to go out of your way to find documentation, understand how to run it, find some more documentation, get "RTFM" replies on their IRC channel.
You've made a few comments implying that if OpenBSD ran some common services by default attackers would get remote root and nothing would stop them. But their services have a pretty good track record:
- OpenSMTPd: 2 remote holes in 10 years
- OpenSSH: 1 remote hole in 10 years
- httpd: No remote vulns
- relayd: No remote vulns
What are you looking at that makes you confident that if OpenBSD ran these by default (which I think is a bad idea in general) they'd have a significantly worse security history?
I don't mean to imply that if OpenBSD ran those specific services by default that it would be much worse.
My point is that:
a) Generally for a server people are running some kind of services, and that's going to include third party software. Not always, but often, and that software is not audited by OBSD team. Even say adding a module to httpd may allow for remote compromise
and
b)
That the tools OpenBSD provides for dealing with an attacker who has managed to gain remote access are insufficient compared to what is available, and especially insufficient for an OS that claims to be focused on security.
> Generally for a server people are running some kind of services, and that's going to include third party software.
Oh so you're saying that things like ASLR, chrooting, and safe programming practices aren't useful in things like httpd, because you might run an insecure PHP app, and the only thing that helps you then is something like SELinux?
I think that's pretty wrong. Running services in a chroot with pledge gives you a lot of security. And the other security features [0] (empirically) help reduce the occurrence of remote vulns overall with far less complexity than SELinux (which also totally weirds your system).
> Oh so you're saying that things like ASLR, chrooting, and safe programming practices aren't useful in things like httpd, because you might run an insecure PHP app, and the only thing that helps you then is something like SELinux?
You sure put in a lot of effort to misconstruing me there. So many people in this thread who are responding emotionally and without the knowledge to really have a proper discussion.
Instead of trying to defend pledge, maybe do some more reading on SELinux and understand just how fundamentally different the approaches are, and why pledge just can't compare.
Sorry, tone is hard over the internet. I've been trying to engage in good faith, but now I'm gonna zoom out a little and say you have a lot of dismissive, low to no-content replies all over this thread, and your reply to me here is a good example. I'm honestly trying to understand your argument! But you didn't help me out even a little bit.
> You sure put in a lot of effort to misconstruing me there.
I assure you I did not, because I was on the toilet (there's a > 50% chance that this is the case with me on HN).
> without the knowledge to really have a proper discussion
This is pretty arrogant and dismissive; you don't have a great way to gauge my knowledge on this other than a no-true-scotsman on "if you knew what I knew about SELinux, you'd agree with me".
> Instead of trying to defend pledge, maybe do some more reading on SELinux and understand just how fundamentally different the approaches are, and why pledge just can't compare.
I'm not really defending pledge, and I'm not offended by the prospect that SELinux might provide superior security. I'm just trying to have a discussion with you. I will suggest that there may be other axes on which to evaluate a security solution. For example, maybe I don't want the complexity of SELinux (it is, by any measure, complex) and OpenBSD's security lets me address my threat model while avoiding SELinux' complexity. Or in other words, maybe I don't care that I can't restrict nginx to only bind to a specific port, I just don't want it serving up arbitrary files out of my filesystems: chroot to the rescue.
Here are some quotes from your other posts:
> lol, ok. You really think root can't access the devices? lol.
Super dismissive!
> If someone has remote root you are telling me they can't unhide a filesystem?
If you know about a bug in OpenBSD's chroot that lets root access any filesystem you should report it. Otherwise, you're making it up and it's not a good argument.
You might be thinking, "Hrmph, I'm just sure it's possible because of the power of root", but I might also be thinking, "Hrmph, I'm just sure there's tons of junk bugs in the monstrous SELinux code base, not to mention unintended interactions with features and other subsystems", which is why we need evidence, of which your posts have none.
> It's ["unhiding" a filesystem as root] absolutely possible. No idea about a proof of concept, but I don't even think it matters, honestly.
Yeah, here we go.
> It's cute that the OS might play some tricks to hide them from you, but at the end of the day, that's all it is doing, is hiding. Security by obscurity.
"cute" and "play some tricks" are dismissive. Again, if you've got a way to jailbreak OpenBSD's chroot you should report it. It's not security by obscurity, you can look up exactly how it works because OpenBSD is FOSS.
> lol, you clearly have no clue.
Also super dismissive.
> pledge and unveil are toys by comparison
"toys" is dismissive.
---
Multiple people have tried to engage with you to try to discuss SELinux vs. OpenBSD's other security features, and your replies have uniformly been, "do some more reading on SELinux", only more rude. If your goal here is to make friends and convince people of the merits of SELinux, my guess is you're actively losing ground with this approach.
You put words in my mouth and seemed to be misconstruing my point. I didn't assume bad faith, but I didn't assume good faith either given that.
> you have a lot of dismissive, low to no-content replies
Yeah, probably. A lot of people are saying ignorant things, like the people claiming if someone got root on SELinux they could just change the SELinux policies.
> you don't have a great way to gauge my knowledge on this
When people say something egregiously wrong, it's helps gauge. It's like if someone is telling me something about the English President I'm probably not going to put too much weight in anything they say about geopolitics.
> I'm not really defending pledge, and I'm not offended by the prospect that SELinux might provide superior security.
Well, that's great, because that's been my only real point, yet plenty of people do seem to be offended by exactly what you say you personally are not.
> I'm just trying to have a discussion with you.
I apologize profusely for being more hostile than is warranted then. I much prefer to discuss this stuff as I am passionate about it. But there are a ton of people responding emotionally with tired arguments, and it becomes a chore to reply when no good faith discussion is taking place.
> I will suggest that there may be other axes on which to evaluate a security solution. For example, maybe I don't want the complexity of SELinux (it is, by any measure, complex) and OpenBSD's security lets me address my threat model while avoiding SELinux' complexity. Or in other words, maybe I don't care that I can't restrict nginx to only bind to a specific port, I just don't want it serving up arbitrary files out of my filesystems: chroot to the rescue.
I wouldn't dispute that for a second. I agree SELinux or similar isn't needed for every use case. My point was that OBSD, if it wants to be a security focused OS and taken seriously as such, should offer something along those lines. It doesn't have to be as complex, but they should have something.
Instead, you have people suggesting and advocating for things that are not remotely similar, but are the closest and best OpenBSD has to offer along those lines, which IMO are not good enough.
> "Hrmph, I'm just sure it's possible because of the power of root",
Pretty much, yeah, except it's hardly a stretch like you are making it seem. If I can run code as root, I can find those files as devices if I'm determined enough, absolutely, even if I have to interact with devices directly and bypass the filesystem.
> Hrmph, I'm just sure there's tons of junk bugs in the monstrous SELinux code base, not to mention unintended interactions with features and other subsystems
Sure, although unlikely. Pretty sure SELinux (not Linux) has a better track record than OBSD for serious bugs, and none that have allowed full compromise unlike with OpenBSD.
The point, again, is not so much to advocate for SELinux (I prefer RSBAC myself anyway), but that OpenBSD should have something that fills the same niche. It doesn't have to be as complex, it doesn't have to be a full implementation, but they should have something. And they don't.
> "cute" and "play some tricks" are dismissive
Yes, because I'm dismissive of those technologies in the context they were brought up in.
> "toys" is dismissive.
Yup.
> Multiple people have tried to engage with you to try to discuss SELinux vs. OpenBSD's other security features, and your replies have uniformly been, "do some more reading on SELinux", only more rude.
OSS OSes like OBSD are tribal. People defend them out of emotion very often, just as much as people defend sports teams or religions. A lot of the replies are bad. There are people defending OpenBSD claiming it does what SELinux, or trying to discredit SELinux without seemingly even knowing core basics about it.
As far as I'm concerned, the quality of my replies is proportional to the comments I am replying to.
> You put words in my mouth and seemed to be misconstruing my point.
I'm just trying to put meat on the bones of your argument, which I thought was: "'secure by default' by OBSD basically just means everything disabled by default." Seems reasonable to infer that you meant if I enabled some stuff I'd have significantly more remote holes, which didn't seem true. You then said that wasn't your argument:
> Generally for a server people are running some kind of services, and that's going to include third party software. Not always, but often, and that software is not audited by OBSD team. Even say adding a module to httpd may allow for remote compromise
I think "an insecure PHP app" qualifies as third party software, and it sounds like unveil/pledge/chroot mitigates the scenario you're describing. Can you explain why that's a bad example, and do you have a better one?
> like the people claiming if someone got root on SELinux they could just change the SELinux policies
In fairness, this isn't unlike your claim that you can bit-twiddle raw devices in a chroot to find a filesystem ("If you have root, you have access to the files, period. Someone determined enough could search, read and write to the disk directly, bypassing the filesystem"). Well, there are differences: in a chroot you don't have access to the raw devices and OpenBSD's default securelevel already mounts them read-only besides.
> My point was that OBSD, if it wants to be a security focused OS and taken seriously as such, should offer something along those lines.
> Pretty sure SELinux (not Linux) has a better track record than OBSD for serious bugs, and none that have allowed full compromise unlike with OpenBSD.
SELinux has a huge attack surface, and has had a lot of privilege escalation and code execution bugs [0]. I know it's kind of a polemic, but hard to not call it a rootkit at this point. I think OpenBSD deciding to not build something like it is a pretty good security choice. It's probably a good idea that root is just another user, but privesc means becoming any user, so in the wake of those vulns that design choice doesn't buy you very much.
> As far as I'm concerned, the quality of my replies is proportional to the comments I am replying to.
I get where you're coming from here--and I've definitely done it myself--but that's the kind of thing that lowers the quality of discussion here. You can't control what other people post, but you can control how you respond.
> I'm just trying to put meat on the bones of your argument,
If you were uncertain about something, why not just ask?
> I think "an insecure PHP app" qualifies as third party software,
mod_php would be, not the php app itself.
> and it sounds like unveil/pledge/chroot mitigates the scenario you're describing. Can you explain why that's a bad example, and do you have a better one?
It's a bad example because it's not really a separate app so much as it is a slight extension to httpd that might introduce some insecurities.
A better example would be running an actual app...a database for example, maybe an irc server, a jabba server, anything that listens on it's own port and accepts network connections.
unveil/pledge/chroot won't mitigate any scenario where an attacker has remote root to satisfaction.
> In fairness, this isn't unlike your claim that you can bit-twiddle raw devices in a chroot to find a filesystem
It's radically different. You would have to leverage root to gain access to another user that isn't managed by the system, and where you have no real access despite being root. There is no pathway to do what you suggest. At all.
> in a chroot you don't have access to the raw devices
We're not going to agree on this at all lol. chroot as protection is just fundamentally weaker and it should ONLY be part of defense in depth, while you and other people seem to be happy with it as almost a final solution.
chroots can be escaped, the openbsd team even warn of this on the manpage for their own chroot.
> SELinux has a huge attack surface, and has had a lot of privilege escalation and code execution bugs
Sure, but none of which can be utilized in the way you suggest is possible. Got an example that shows otherwise?
> but hard to not call it a rootkit at this point.
Well that's ridiculous.
> I think OpenBSD deciding to not build something like it is a pretty good security choice.
And that's flat out wrong. You're not keen on selinux because of the complexity, but not all implementations have to be that complex. Look at things like rsbac and apparmor.
> so in the wake of those vulns that design choice doesn't buy you very much.
This just doesn't make sense, period. On an SELinux system, you won't be able to simply switch to the policy administrator and give yourself whatever access you want. That shows IMO a fundamental misunderstanding of how SELinux works.
So which of these allow for a restricted root to switch a user with a role that can administer SELinux policies, and how would the attacker find out which user that is?
>> I think "an insecure PHP app" qualifies as third party software,
> mod_php would be, not the php app itself.
I don't see a difference here. Why does it matter if mod_php sends all your SSH keys or cool_app.php does? What would SELinux prevent here that pledge/chroot wouldn't?
> A better example would be running an actual app...a database for example, maybe an irc server
OpenBSD's ngircd has a pretty good track record [0]. The out-of-bounds read in CVE-2020-14148 isn't great, but chroot/pledge/not running as root mitigates a lot of badness. Can you explain what SELinux would prevent here that OpenBSD's security features don't? It sounds like on either system you'd be limited either to whatever the confined process can do, or to whatever the chroot/pledge/user can do. Aren't these just different ways of specifying capabilities? What capabilities would SELinux restrict that OpenBSD wouldn't let you? BTW this is an opportunity to sell me on SELinux--I am genuinely curious here. I mostly think the RBAC in UNIXish systems doesn't do the trick anymore, because appsec is so much more complicated.
> unveil/pledge/chroot won't mitigate any scenario where an attacker has remote root to satisfaction.
How would you get remote root from CVE-2020-14148? Or is there another example you're working off of? It's empirically pretty hard to get remote root on OpenBSD, and you've yet to find a module or an internet-facing app that would have let you do it. Your "remote root" claim is so far a claim without evidence.
> There is no pathway to do what you suggest. At all.
I agree! You're the one saying you can get access to raw devices and do whatever you want with them regardless of security features. I'm saying if this is true it applies to both your claims about OpenBSD's security features and SELinux. But I think this is another unbacked claim from you.
>> in a chroot you don't have access to the raw devices
> We're not going to agree on this at all lol.
Well, another way of saying this is that you've yet to persuade anyone that you can jailbreak OpenBSD's chroot. You continue to make this claim that it's "a toy" and such, but despite that it seems like it's doing the job. If you want to convince people that SELinux does what chroot doesn't, you gotta give an example, which you've yet to do.
>> SELinux has a huge attack surface, and has had a lot of privilege escalation and code execution bugs
> Sure, but none of which can be utilized in the way you suggest is possible. Got an example that shows otherwise?
Sure, the 1st privesc bug [1] has a pretty detailed write-up on Project Zero's mailing list. Privesc doesn't just mean getting UID 0, it means getting any UID you want--or in this case, any SELinux context you want. Doesn't this totally circumvent SELinux?
>> so in the wake of those vulns that design choice doesn't buy you very much.
> This just doesn't make sense, period. On an SELinux system, you won't be able to simply switch to the policy administrator and give yourself whatever access you want.
I'm reading [2], where you do `usermod -Z <selinux user> <linux user>` as root to map Linux users to SELinux users and [3] where you do `semanage login -m -s <selinux user> <linux user>`. How does SELinux stop me from doing that? I assume if I'm mapped to secadm_r I can do whatever I want here, so how would SELinux prevent me from privescing to a user with that mapping and running
these commands?
> Look at things like rsbac and apparmor.
The rsbac patch for 6.1.15 is > 120KLOC [4]. That's hefty to me.
Has been in the 'disk setup' part of the FAQ for quite a long time I think. Do you have special requirements e.g. external key disk or something unusual?
If you don't understand a system it's by definition not secure, keep your hands away or start learning your stuff, or at least don't call it secure (the big word that includes many different meanings)
The OpenBSD developers know that their users take security seriously, over convenience and just-works installers.
So it's a safe bet that OpenBSD users will take the few extra (well-documented) manual steps to encrypt their storage devices, leaving the developers to focus on things that are not easy for users to do for themselves.
Adding the convenience to the interactive installer is clearly a good thing, but it would not be at the tippy-top of the priority list if you have limited funding and developer time.
I mean, is that not like saying that a user will RTFM and disable all unnecessary services after their install?
The OpenBSD mentality is the opposite - they will sacrifice convenience and disable all unnecessary services by default, in order to make the system as secure as possible, and you can go RTFM and knowingly increase your risk if you choose to.
That mentality would suggest, I think, disk encryption should be opt-out on the install. Of course, the first step to getting there is an opt-in system.
In this case (disk encryption) the process is simple, but the data collection and then things like back/fwd, changes, accept etc.. makes it more complicated than a simple boolean/checkbox.
So the compromise was "bounce to the docs for this one", until this new improvement was added.
Encryption doesn't necessarily make a system more secure. For many normal desktop users data integrity is more important than full-disk encryption. Data integrity and encryption are principally opposed to each other and create a trade-off. Encryption adds many additional points of failure and makes data recovery hard, sometimes even impossible. I would recommend full-disk encryption for most laptop users who carry their laptop with them, though.
Besides the obvious reason of it being a brand new feature of the installer, one reason may be the "hassle" that full-disk encryption comes with. FDE isn't just "home directory encryption", which unlocks automatically when you log in. It requires manual password entry (or key-disk provisioning) in order to init and load the kernel at all.
Wild guess: It was commited only 1 day ago, this is considered initial support and need to be tested, previous openbsd users are used to drop to a shell and set it manually and thus might have already encrypted the disk when they reach that step.
I tried installing OpenBSD a few times and could never get past partitioning and encrypting my disk. Yes, I could probably have gotten it to work if I was willing to fiddle with it/read some blog posts. But I'd rather just run Linux :)
Heh, compared to Linux encrypting a disk was dumb easy. Once you set the bioctl devices,
you usually chose sd1 or sd2 depending on the layout and literally apply the same instructions
af it was sd0. Done.
With Linux, crypsetup and lvm I wanted to kill myself.
> With Linux, crypsetup and lvm I wanted to kill myself.
With what, Linux from scratch or something? Eg: Debian has had "encrypt disk" in the installer for a long time. Granted, if you want a super custom setup - it's trickier - but then it kind of is inherently more complex.
Slackware, Arch, and most non-Debian and Fedora based distros. And, even on Debian/Fedora derivs, on troubleshooting, encrypting HD drives under GNU/Linux has always been hell.
Slackware is pretty manual I admit. The installer does not actually provide an automatic partitioning scheme at all, you boot from the installation media, set the keyboard, and drop into a root shell and run fdisk/cfdisk on the fixed disk you want to install to and set up your partitions as you want. That is for any installation, unencrypted or encrypted.
Using an lvm set up is about half way through the document above. These docs come on the installation media. Same kind of idea as with OpenBSD - partition hard drive so small partition just to boot off then the rest of the disk to house encrypted lvms with swap, home, root whatever. Then run the 'setup' program as usual to actually install to your lvms.
Other distributions (e.g. RHEL/Debian based) make it a push button exercise.
You're right that this thread broke out into hellflames. We've banned the worst offenders and scolded some of the others. I don't think it's representative of HN, though. My take is that it was the old-school pull-no-punches style of some systems-oriented communities showing up on HN without adjusting for the cultural context shift. I could be wrong about that though.
I hope that we don't start demoting visibility to the point that it's nowhere to be found somewhere in the first 10 pages after hitting the front page even if it's bad. It don't feel it represents our users from the fringe.
If you're going to demote, don't take it off the main page index for casual browsers. Sometimes the fringe is very correct.
HN's practices around this have been well-established for many years. Flamewars tend to get demoted off the front page (mostly by software) while sensational or repetitive stories tend to get demoted by moderators.
The current thread spent 9 hours on the front page, which is a lot. It did set off the flamewar detector but it looks like we switched that off. Other than that, moderators didn't touch it.
No. OpenBSD had it as an optional method in the FAQ and man pages.
The encryption guide was already there, but not shown in the installer.
You had to run three or four short commands by spawning a shell with '!' from the installer, exit that shell and that's it.
Now try doing the same by hand under Linux. With an encrypted boot.
It is true, encrypted /boot on Linux (i.e. where the Linux kernel lives) is time-consuming and error-prone to setup, even if you have been using Linux for years. GRUB only understands LUKS version 1, and is poorly optimised, meaning LUKS' default "2 seconds of password hashing" during install/setup from a running Linux OS takes significantly (!) longer when booting via GRUB. It is the age-old cathedral/bazaar issue.
Sometimes adding a user interface to a straightforward operation is complicated, expensive, time-consuming, and/or low-priority for the intended audience.
OpenBSD users know how to partition and encrypt their disks.
World domination was never on BSD's todo list!
Don't get me wrong -- the Linux way is also perfectly valid, and obviously more popular. But it's not the only way.
I think/assume OpenBSD is mainly used as a server OS. Yes, passionate people use it as a desktop but those mostly read the FAQ anyway.
Currently and as far as I know, bioctl does only support user typed in passwords or key disks. You certainly want also encrypted disks on your server but requiring user typed in password is oftentimes a no-go (think of various firewall appliances doing a reboot and not having remote hands). A compensation can be the key disk but I don’t know how widely that is used.
Hardware bound encryption like with a TPM is not supported. Also Linux is still exploring here as far as I can tell (no installer offers that).
In sum: I think disk encryption in the current form is not a tradeoff many installations will take.
Also if secure-boot/tpm is not desired or not available systemd can now start openssh very early to allow user to type passphrase and for non systemd system one can use tinyssh-initramfs or dropbear-initramfs depending on keys requirements. Last option is dedicated kvm (which also work for openbsd).
Maybe it is coming now instead of earlier not because of a clear choice, but because to get features in to the project people need to spend their own free time on creating them.
Thank you Klemens Nanni and others for taking the time.
It's only now added as an interactive step in the install script. It has ~always been possible to create a crypto device with the install medium by dropping to a shell: https://www.openbsd.org/faq/faq14.html#softraidFDE
Besides, setting encryption manually and then installing openbsd with its very fast installer has always been faster than using the interactive debian installer so in the grand scheme of things it wasn't that big of a deal.
