7 ms·

You could make a quiz based on "what syscalls does this familiar libc API end up calling". selinux and seccomp are dead ends.

jacobush 7y ago
I don't understand. Why are they dead ends?
- Soft 7y ago
  The problem with seccomp is that it operates at the level of system calls. An application could use seccomp to, for example, restrict what system calls it can invoke. However libraries usually consider what system calls they use an implementation detail that can be changed at any time. This forces the application programmer to pay attention to library internals.
  - staticassertion 7y ago
    An effect system would solve this problem, as new system calls imply new effects, causing a breaking API change.
- raimue 7y ago
  libc functions may need unexpected syscalls. For example, some of the date and time functions will very likely access the filesystem, just to parse /etc/timezone and the corresponding files in /usr/share/zoneinfo/. This is unexpected from the point of the programmer, who did not add any open(2) syscall to their application. Now depending on which libraries are in use, finding out which syscalls are actually required has often to be determined with strace or trial&error through all code paths. And with another version of the library, this set of system calls could even change without any changes to API or ABI, leaving the responsibility to track this to the application programmer.
  - debatem1 7y ago
    This is why seccomp (and SELinux) policy should be the province of the platform developer, not the application developer. That's how it works on Android (disclaimer: I worked on that) and it works very well.
    - temac 7y ago
      It works very well until even kernel hackers hit the very problem we are talking about -- which is precisely the same class of problem that classic GNU/Linux userspace is having when trying to use it -- and then it does not work very well anymore. So maybe in they are some contexts where it kind of work (until it doesn't, like here), but another model which works in more cases would be more useful...
      - debatem1 7y ago
        If you have such a model I would welcome it. But realistically, the complexity in SELinux (mostly) doesn't come from SELinux. It comes from the irreducible complexity of doing general purpose fine grained access control on Linux. You could avoid some of that complexity by building something more opinionated, but it turns out that 99.9% of users do something that only 0.1% of users do. The odds that you break enough to generate the same negative sentiment SELinux has, but without the tools to dog those users out, are quite high.
        temac 7y ago
        Something like pledge seems to have better successes... Maybe a middle ground could be achieved, but honestly I prefer simple proven approaches to grand overcomplicated designs. And it has to be in the kernel (or at least shipped and installed by it) and not just one more userspace layer on top of seccomp or the like, because otherwise I can't update the kernel without the risk of breaking everything, which in the traditional GNU/Linux distro world is an important workflow.
        debatem1 7y ago
debatem1 7y ago
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

jacobush 7y ago

I don't understand. Why are they dead ends?

Soft 7y ago
The problem with seccomp is that it operates at the level of system calls. An application could use seccomp to, for example, restrict what system calls it can invoke. However libraries usually consider what system calls they use an implementation detail that can be changed at any time. This forces the application programmer to pay attention to library internals.
- staticassertion 7y ago
  An effect system would solve this problem, as new system calls imply new effects, causing a breaking API change.
raimue 7y ago
libc functions may need unexpected syscalls. For example, some of the date and time functions will very likely access the filesystem, just to parse /etc/timezone and the corresponding files in /usr/share/zoneinfo/. This is unexpected from the point of the programmer, who did not add any open(2) syscall to their application. Now depending on which libraries are in use, finding out which syscalls are actually required has often to be determined with strace or trial&error through all code paths. And with another version of the library, this set of system calls could even change without any changes to API or ABI, leaving the responsibility to track this to the application programmer.
- debatem1 7y ago
  This is why seccomp (and SELinux) policy should be the province of the platform developer, not the application developer. That's how it works on Android (disclaimer: I worked on that) and it works very well.
  - temac 7y ago
    It works very well until even kernel hackers hit the very problem we are talking about -- which is precisely the same class of problem that classic GNU/Linux userspace is having when trying to use it -- and then it does not work very well anymore. So maybe in they are some contexts where it kind of work (until it doesn't, like here), but another model which works in more cases would be more useful...
    - debatem1 7y ago
      If you have such a model I would welcome it. But realistically, the complexity in SELinux (mostly) doesn't come from SELinux. It comes from the irreducible complexity of doing general purpose fine grained access control on Linux. You could avoid some of that complexity by building something more opinionated, but it turns out that 99.9% of users do something that only 0.1% of users do. The odds that you break enough to generate the same negative sentiment SELinux has, but without the tools to dog those users out, are quite high.
      - temac 7y ago
        Something like pledge seems to have better successes... Maybe a middle ground could be achieved, but honestly I prefer simple proven approaches to grand overcomplicated designs. And it has to be in the kernel (or at least shipped and installed by it) and not just one more userspace layer on top of seccomp or the like, because otherwise I can't update the kernel without the risk of breaking everything, which in the traditional GNU/Linux distro world is an important workflow.
        debatem1 7y ago

debatem1 7y ago

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