4 ms·

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 w

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.

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 ago
  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/Documentation/security/landlock.rst https://raw.githubusercontent.com/torvalds/linux/master/Docu...
  - Zurrrrr 4y ago
    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.
    - ori_b 4y ago
      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.
- witheld 4y ago
  > 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

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.

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 ago
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/Documentation/security/landlock.rst https://raw.githubusercontent.com/torvalds/linux/master/Docu...
- Zurrrrr 4y ago
  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.
  - ori_b 4y ago
    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.
witheld 4y ago
> 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