6 ms·

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?

ori_b 4y ago
> 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.
- Zurrrrr 4y ago
  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.
  - ori_b 4y ago
    How? you don't have access to the devices. They're not in your namespace. Again, proof of concept please.
    - 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 ago
        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.
        ori_b 4y ago
        [flagged]
        witheld 4y ago
        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.
        Zurrrrr 4y ago
        And I don't think you understand just how many syscalls big third party applications are going to require.
        witheld 4y ago
        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

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

Zurrrrr 4y ago
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.
- ori_b 4y ago
  How? you don't have access to the devices. They're not in your namespace. Again, proof of concept please.
  - 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 ago
        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.
        ori_b 4y ago
        [flagged]
        witheld 4y ago
        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.
        Zurrrrr 4y ago
        And I don't think you understand just how many syscalls big third party applications are going to require.
        witheld 4y ago
        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...