5 ms·

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
        I mean, SELinux is deployed successfully on north of a billion devices with essentially no false positives and a huge ecosystem to support. It would seem that it has been proven, and at a considerably larger scale than pledges. Not sure where else to go with that.
        7y ago

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
        I mean, SELinux is deployed successfully on north of a billion devices with essentially no false positives and a huge ecosystem to support. It would seem that it has been proven, and at a considerably larger scale than pledges. Not sure where else to go with that.
        7y ago