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.