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