Initial support for guided disk encryption in OpenBSD installer
undeadly.org
undeadly.org
Windows has this, and it permits booting without a passphrase being entered, but the disk will still be encrypted at rest.
That a thief opens your laptop and steal the harddrive instead of the complete machine?
Or is this just a solution that is meant to check a checkbox to make an auditor happy?
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.
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.
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...
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.
https://access.redhat.com/documentation/en-us/red_hat_enterp...
Looks like clevis is gpl3 - so I expect it's not packaged as standard for any of the bsds?
https://github.com/latchset/clevis
See also:
Ed: and: https://github.com/kmille/cryptboot
https://security.stackexchange.com/questions/194081/use-tpm2...
https://security.stackexchange.com/questions/39329/how-does-...
https://superuser.com/questions/619721/can-i-use-the-tpm-on-...
https://github.com/01org/tpm2.0-tools http://trousers.sourceforge.net
You can also emulate a TPM in recent versions of QEMU...
https://tpm2-software.github.io/2020/10/19/TPM2-Device-Emula...
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:
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).
Might the world be a bigger place than you think?
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.
>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.
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...
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!
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.
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).
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).
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).
https://man.openbsd.org/pledge https://man.openbsd.org/unveil
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.
https://www.diva-portal.org/smash/get/diva2:5365/FULLTEXT01.... (2006)
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.
Capsicum?
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.
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.
SEBSE is a Framework, MAC is an implementation, those are two different things on different levels.
>MAC framework, but I've never heard of it. What is it called?
It's called MAC...you still don't see the difference?
https://docs.freebsd.org/en/books/handbook/mac/
Look i stop here you have obviously no knowledge of MAC.
>I've been dealing with MAC for 20 years
Yeah no you don't since you don't even know the difference of SELinux and the/a MAC implementation.
> 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.
The irony here lol.
Please don't reply to me again.
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 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.
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.
pledge and unveil are toys by comparison.
Can you show me a proof of concept here?
Yes. There is no mechanism at all to unmask the vnode. If you believe otherwise, I'd like to see a proof of concept.
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.
Again, proof of concept please.
So you just want to have blind faith in what is basically security via obscurity with extra steps.
That's fine, but it's not an approach to be taken seriously or advocated.
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 don’t get any kind of god powers like kernel memory access, if you don’t have access to the system call you can’t debug.
Like I don’t understand how to explain to you that SELinux locks down system calls in an identical way conceptually.
If you can actually exploit a system call, neither a MAC based approach or a pledge will help.
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.
MAC will, pledge won't.
For example with SELinux:https://www.kernel.org/doc/Documentation/prctl/seccomp_filte...
Linux has added a direct pledge+unveil clone to improve the situation: https://raw.githubusercontent.com/torvalds/linux/master/Docu...
That's not a 'weaker version of pledge', it's part of a much larger framework with much greater enforcement capabilities.
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.
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.
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.
Not so, not so at all. You have to take my statement in context.
The point was those technologies, while nifty, are entirely irrelevant if an attacker gains remote root.
Semantics doesn't change that.
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.
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.
I'm not talking about GETTING root, I'm talking about in the situation where an attacker already HAS root.
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'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.
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.
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.
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.
SELinux and similar frameworks do prevent further compromise.
That's 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?
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.
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.
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.
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.
#include <stdio.h>
#include <unistd.h>
#include <err.h>
#define CHROME_MAIN_CONTENT_PLEDGE \
"rpath wpath cpath stdio tmppath dns inet flock "
"unix proc prot_exec tty sendfd recvfd exec mcast "
"ps drm fattr route getpw vminfo video"
int
main(int argc, char **argv)
{
if(argc < 2)
errx(1, "usage: %s cmd\n", argv[0]);
if(pledge(CHROME_MAIN_CONTENT_PLEDGE, CHROME_MAIN_CONTENT_PLEDGE) == -1)
err(1, "pledge");
if(unveil("/var/empty", "r") == -1)
err(1, "unveil");
if(unveil(NULL, NULL) == -1)
err(1, "unveil");
execv(argv[1], &argv[1]);
err(1, "exec");
}
cc -o asroot asroot.c
doas ./asroot your-exploit-command
How about you show me how you lock down an OBSD system that is running, say Oracle. With pledge.
Though I'm not sure why you think it'd be much harder than pledging Chrome or Firefox.
If you want t discuss this further, illustrate how pledge can protect against a remote root exploit in Oracle as good or better than SELinux can.
What operations would you use to break out of the above sandbox? Once you give me that, I'll happily discuss the details.
I'm not interested in retreading anything. I don't even want to continue discussing anything with you as it is, but I'm willing to see where this goes.
Show how pledge can protect against a remote root compromise in oracle. I doubt it can, you've been insisting pledge is all OpenBSD needs to protect against such attacks.
I'm not answering any more questions or taking any more detours. Stop being intellectually dishonest.
Either admit that you don't know for sure that pledge can protect against a remote root compromise in complex third party software like oracle and simply think it can, or show how it can.
If you can't do that, we're at an impasse and there won't be further discussion. Unless you post some kind of baiting comment I suppose, which wouldn't surprise me at this point.
The program upthread will let you do that.
It won't be as good as Oracle doing its own pledges, of course, because well pledged programs narrow down their pledge set as they run -- but if you have a binary that you can't modify, this is as good as you can do with any security framework. For example, Linux has landed on the same model as pledge when they added landlock, where a program is expected to landlock itself after opening the initial handles to resources.
And if it needs access to an awful lot of data across the file system or raw devices (which is not uncommon for complex proprietary commercial software), what then?
> It won't be as good as Oracle doing its own pledges, of course
And that's part of the issue, because you can't count on or only use software which is making pledges, and no commercial software will at all.
> but if you have a binary that you can't modify, this is as good as you can do with any security framework.
This is where a MAC framework has a strength and advantage over pledge.
With pledge/unveil and oracle, you likely won't be able to sufficiently restrict access to data or devices to prevent lateral movement and prevent further compromise, as complex programs like that require too much access to function correctly.
With a MAC framework you can. Now the binary has no access to certain parts of the filesystem in a way that is much more secure than a chroot, only has access to syscalls it needs (on par with pledge here), can't execute other binaries, can't make library calls, can't access devices (e.g. tty, network), can't switch user context, can't do anything as root even if root were obtained, can't write to ANY files only append, can't delete ANY files, etc etc etc. You have complete granular control over many more aspects of what to permit or deny.
Pledge and unveil simply can't compare. In some scenarios they may be sufficient, but in most, and certainly in most where an attacker has root, they are not.
The same thing as any other framework. You either grant it access, or you don't. The list of files just gets long.
> And that's part of the issue, because you can't count on or only use software which is making pledges, and no commercial software will at all.
Luckily, you can pledge and unveil from outside the process, as the code above does. Once more, that runs an arbitrary command under pledges and unveils.
The thing lost is the ability reduction in access during the program lifetime, which is something that can only be done with the cooperation of the binary running; you don't have enough information to know when (for example) the code setting up the last network listener needed has been run without the help of the binary. You don't get that in most security frameworks anyways, so this is not a weakness in comparison to them.
> With a MAC framework you can. Now the binary has no access to certain parts of the filesystem in a way that is much more secure than a chroot, only has access to syscalls it needs (on par with pledge here), can't execute other binaries, can't make library calls, can't access devices (e.g. tty, network), can't switch user context, can't do anything as root even if root were obtained, can't write to ANY files only append, can't delete ANY files, etc etc etc. You have complete granular control over many more aspects of what
Yes, that's what you get with pledge and unveil.
If you think otherwise -- I gave you a program that runs any arbitrary binary; please show a demo of a jailbreak.
No. Not even close. You're missing the point.
There is a fundamental difference which you are ignoring or blind to.
With something like pledge, you can't limit anywhere near as much as what you can limit with a MAC framework.
This means with pledge, you can only limit to what the program needs, which may well be enough (and with something like Oracle it's almost guaranteed) for an attacker to escape whatever confines you think you have in place. That simply isn't true for a MAC framework where you can limit to a greater extent and with a lot more granularity.
> Luckily, you can pledge and unveil from outside the process, as the code above does.
That doesn't help even slightly and has no bearing on the point I made.
> Yes, that's what you get with pledge and unveil.
Jesus christ no you don't. Not even close. At this point it's abundantly clear you are not familiar with MAC frameworks at all, and you're just convinced that pledge and unveil are the same thing. That's willful ignorance and nothing more.
> If you think otherwise -- I gave you a program that runs any arbitrary binary; please show a demo of a jailbreak.
You haven't shown that pledge and unveil are as good at SELinux at locking down something like Oracle, you're just claiming it is with hand waiving. pledge and unveil simply don't offer what SELinux does, and you're just dismissing that and insisting they do.
Ridiculous.
Go ahead, tell me a specific thing that I can't limit with pledge and unveil. Note that everything you mentioned when discussing Oracle could be done with them.
I've provided code. You haven't even listed a threat model. You just yelled a bit about root escapes, and then when challenged to provide an example, yelled about Oracle. And then yelled a bit about how MAC provides more, without any specifics about which relevant 'more' it provides. (I certainly agree that it's more flexible, more complicated, and more difficult to configure -- but not that it's more secure).
Again, there's example code sitting right there, which can be used for something like Oracle. Prove that there's an escape.
Sigh. I've listed numerous examples, and like a dipshit you just change a few words in my reply and parrot it back at me, without seemingly comprehended a thing.
At this point you are just displaying zealotry. Even Theo disagrees with you.
> I've provided code.
Fucking exactly. That shows that you are not following the discussion at all, just blindly defending your niche OS.
We were talking about complex third party programs that are hard to lock down. A short code example using pledge is, now make sure you read these next few words and try to absorb them, entirely fucking irrelevant.
We're not talking about software developers trying to prevent exploitation of trusted code, we're talking about trying to lock down untrusted code in the event of a compromise.
> You just yelled a bit about root escapes, and then when challenged to provide an example, yelled about Oracle. And then yelled a bit about how MAC provides more, without any specifics about which relevant 'more' it provides.
No, I gave specific examples, and you just hand waived them and asserted pledge and unveil offer the same capabilities and defenses without bothering to show how.
> Again, there's example code sitting right there, which can be used for something like Oracle
No it fucking can't, at all, it's entirely irrelevant and has no relationship to oracle at all. Are you on the spectrum or something? How are you failing to follow this discussion to this extent? It's honestly baffling.
That short code example LOCKS DOWN AN ARBITRARY THIRD PARTY PROGRAM that you pass it as a command line argument. I skipped arg parsing for simplicity, but it does exactly what you're asking for.
> No, I gave specific examples
Can you point to the code you posted that breaks out of the sandbox I gave? I seem to have missed it.
> That short code example LCOKS DOWN A COMPLEX THIRD PARTY PROGRAM. The fact that you haven't understood this shows that you're not understanding the discussion.
It doesn't do a fucking thing to lock down Oracle you absolute twit. Oracle won't even start if you try to limit it as though it were Chrome.
Why is it somehow not in the least bit surprising that you a) think that would work and b) think it's a viable solution.
Sigh. This is honestly so fucking stupid.
Pledge can ONLY restrict a program to the syscalls it needs. If the program needs syscalls which can be used to leverage an escape or escalation, pledge is fucking useless. SELinux doesn't have that weakness. That you don't understand this fundamental difference shows you're out of your depth, and that as suspected you're a waste of time to try and educate.
I'm not going to reply to you again given how technically illiterate you are in this context. Given how insecure and religious towards OpenBSD you seem to be, I'm assuming you're going to need to have the last word, and likely will yet again just parrot back a paraphrased version of one of my replies to you...yet again demonstrating your lack of originality or comprehension.
Have fun with that, and I hope having the last word gives you that little boost of self-confidence you seem to be craving to compensate for your clear lack of knowledge.
Best of luck to you in life. You need it.
I'm sure you know a lot and I normally wouldn't ban an account without warning at least once first, but the way you behaved in this thread was just way too extreme. I know this sort of no-holds-barred flamewar is standard in some systems-oriented communities and I don't have any judgment about that, but HN is much larger and we can't afford to have accounts posting like this—it would lead straight to the self-incineration of this site (by masses of people who likely know a lot less than you do).
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.
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.
I'm not remotely wrong about OpenBSD, and that manpage doesn't contain anything that contradicts a point I've made.
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.
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.
As a concrete example, Firefox can only load/save or download files to ~/Download by default.
https://www.openbsd.org/faq/faq14.html#softraidFDE
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.
Yes, I said theirs, because since then I want nothing to do with that.
"Unix grey beards are forged in suffering".
Yeah, well, suffer if you'd like, but I have better things to do with my time.
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.
Doesn't seem very secure by default to me.
Look, I was just trying OpenBSD with an open mind, and I met people who were unhelpful.
Even in the street if I asked someone for the time and he said "get a watch", it would be rude.
I understand that they don't want to help. But do they need to be rude about it?
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)
Can't hack anything if nothing is running, right? Only issue is it's not that useable either.
- 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?
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.
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).
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.
> 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.
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.
[0]: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=selinux
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.
> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=selinux
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?
> 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.
[0]: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ngircd
[1]: https://bugs.chromium.org/p/project-zero/issues/detail?id=22...
[2]: https://access.redhat.com/documentation/en-us/red_hat_enterp...
[3]: https://rhel7stig.readthedocs.io/en/latest/medium.html#v-719...
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.
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.
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
- there it was.
For a broader understanding there’s always:
What I'm saying is: it's probably a great OS with great documentation, but the community isn't welcoming at all.
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).
https://www.openbsd.org/faq/faq4.html#FilesNeeded
> 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.
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.
https://www.openbsd.org/faq/faq14.html
It’s 3 commands to type in that are explained and that will work as is in most cases.
And then there are the other cases. Then you ask the community. And again, not welcoming etc.
I am pretty sure nobody said that and you invent it.
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.
http://slackware.uk/slackware/slackware64-15.0/README_CRYPT....
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.
If you're going to demote, don't take it off the main page index for casual browsers. Sometimes the fringe is very correct.
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.
Thank you Klemens Nanni and others for taking the time.
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.
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.
True, OTOH AFAIK you can add tpm unlock to a typical luks setup after installation, see my other comments:
https://news.ycombinator.com/item?id=35067375 (ed: fixed)
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).
Yes, it was. Fixed, thank you.
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.