4 ms·
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
by Zurrrrr 4y ago
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.
- ori_b 4y ago[flagged]
- Zurrrrr 4y agoI'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.
- ori_b 4y ago[flagged]
- witheld 4y agoYou 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.
- Zurrrrr 4y agoAnd I don't think you understand just how many syscalls big third party applications are going to require.
- witheld 4y agoThey 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.
- Zurrrrr 4y ago> 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_filter.txt https://www.kernel.org/doc/Documentation/prctl/seccomp_filte...
- ori_b 4y agoDid 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/Documentation/security/landlock.rst https://raw.githubusercontent.com/torvalds/linux/master/Docu...
- Zurrrrr 4y agoStop 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.
- ori_b 4y agoI'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.
- dang 4y agoPlease 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 https://news.ycombinator.com/newsguidelines.html and not do this kind of thing in the future, we'd appreciate it.