Hacker News Reader

Comment by jmclnx | Hacker News Reader

What ?

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.

View on HN

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.

pledge and unveil are toys by comparison.

>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.

> That statement indicates you do not fully understand pledge(2) and unveil(2).

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.

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.

A car can have all the tech in the world to avoid an accident, but I still expect it to have seatbelts.

> Hiding filesystems is security via obscurity more than anything else, and probably won't hold up if someone has root.

Can you show me a proof of concept here?

If someone has remote root you are telling me they can't unhide a filesystem? Otherwise what are you disputing and what would you accept as evidence?

> If someone has remote root you are telling me they can't unhide a filesystem?

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 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.

How? you don't have access to the devices. They're not in your namespace.

Again, proof of concept please.

lol, ok. You really think root can't access the devices? lol.

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.

[flagged]

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.

[flagged]

You don’t understand namespaces, there are no mechanisms, or root specific mechanisms, you could use to elevate a namespace.

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.

And I don't think you understand just how many syscalls big third party applications are going to require.

They aren’t (and do not) require any privleged system calls, whatsoever.

If you can actually exploit a system call, neither a MAC based approach or a pledge will help.

> 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.

MAC will, pledge won't.

For example with SELinux:https://www.kernel.org/doc/Documentation/prctl/seccomp_filte...

> 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

Did you realize your link points to a more fragile version of pledge?

Linux has added a direct pledge+unveil clone to improve the situation: https://raw.githubusercontent.com/torvalds/linux/master/Docu...

Stop spreading misinformation. Hell stop replying to me. You're basically a cultist at this point with your irrational emotional devotion.

That's not a 'weaker version of pledge', it's part of a much larger framework with much greater enforcement capabilities.

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.

Reply on news.ycombinator.com