3 ms·

Yet somehow we run SELinux successfully on every Android device. I've never understood the antipathy towards SELinux (which by the way, doesn't operate at sysca

Yet somehow we run SELinux successfully on every Android device. I've never understood the antipathy towards SELinux (which by the way, doesn't operate at syscall granularity).

nickpsecurity 7y ago
There were also enterprise and military customers using it for damage reduction. Some used products from Tresys that made configuration easier. Unfortunately, the tremendous number of 0-days and leaks in Linux platform made high-assurance community push for putting apps in VM's on separation kernels. The rise in hardware attacks meant even those aren't enough: physical separation with EMSEC sheilding is required. Most aren't going to do that, though. So, their boxes are still nice targets.
yjftsjthsd-h 7y ago
> I've never understood the antipathy towards SELinux Most people first encounter it when it breaks their program in opaque and surprising ways. They then dig in... to find that the solution is non-obvious. So they turn it off and remember it as that thing that breaks stuff.
d2mw 7y ago
One reason to dislike SELinux is the arbitrary assumptions baked in by default that barely anyone knows how to or cares to change, which makes carefully designed software look broken when the framework itself is broken. One example I've faced is UNIX pipes, which for all purposes were obsoleted by UNIX domain sockets in the mid 80s as part of the original intent of the BSD socket API, but to SELinux they are profoundly different things. You can pass pipes across a user->root boundary but not a socket. To the end user, they only see your code broken by SELinux, and assume you haven't done your job. On the other hand, SELinux is codifying rules about UNIX that never existed and amount to emotional heuristics about the risk of Internet domain sockets being inherited around the system by the wrong process. The effect isn't to prevent Internet domain sockets being inherited by privileged processes, but breaking all sockets. That's garbage design, hidden behind marketing suggesting because the NSA contributed some code that the problem couldn't possibly be SELinux
- debatem1 7y ago
  But unix domain sockets are not pipes, not least in the important way that you can reliably determine the identity of the other end. That can in some cases be an infoleak, and therefore needs independent access control.
  - d2mw 7y ago
    If SCM_CRED passing were a real problem in _any_ scenario, SELinux should target that instead, not an entire subsystem on which half the system is built
    - debatem1 7y ago
      The point is you need the ability to express both "these are the same thing" and "these are different". You can do both with SELinux. What's your alternative?
      - deleted 7y ago
        [deleted]

Yet somehow we run SELinux successfully on every Android device. I've never understood the antipathy towards SELinux (which by the way, doesn't operate at syscall granularity).

nickpsecurity 7y ago

There were also enterprise and military customers using it for damage reduction. Some used products from Tresys that made configuration easier. Unfortunately, the tremendous number of 0-days and leaks in Linux platform made high-assurance community push for putting apps in VM's on separation kernels. The rise in hardware attacks meant even those aren't enough: physical separation with EMSEC sheilding is required. Most aren't going to do that, though. So, their boxes are still nice targets.

yjftsjthsd-h 7y ago

> I've never understood the antipathy towards SELinux Most people first encounter it when it breaks their program in opaque and surprising ways. They then dig in... to find that the solution is non-obvious. So they turn it off and remember it as that thing that breaks stuff.

d2mw 7y ago

One reason to dislike SELinux is the arbitrary assumptions baked in by default that barely anyone knows how to or cares to change, which makes carefully designed software look broken when the framework itself is broken. One example I've faced is UNIX pipes, which for all purposes were obsoleted by UNIX domain sockets in the mid 80s as part of the original intent of the BSD socket API, but to SELinux they are profoundly different things. You can pass pipes across a user->root boundary but not a socket. To the end user, they only see your code broken by SELinux, and assume you haven't done your job. On the other hand, SELinux is codifying rules about UNIX that never existed and amount to emotional heuristics about the risk of Internet domain sockets being inherited around the system by the wrong process. The effect isn't to prevent Internet domain sockets being inherited by privileged processes, but breaking all sockets. That's garbage design, hidden behind marketing suggesting because the NSA contributed some code that the problem couldn't possibly be SELinux

debatem1 7y ago
But unix domain sockets are not pipes, not least in the important way that you can reliably determine the identity of the other end. That can in some cases be an infoleak, and therefore needs independent access control.
- d2mw 7y ago
  If SCM_CRED passing were a real problem in _any_ scenario, SELinux should target that instead, not an entire subsystem on which half the system is built
  - debatem1 7y ago
    The point is you need the ability to express both "these are the same thing" and "these are different". You can do both with SELinux. What's your alternative?
    - deleted 7y ago
      [deleted]