5 ms·

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/timezon

by 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.
        naniwaduni 7y ago
        I'll believe "essentially no false positives" when people don't set SELinux enforcement to permissive and forget about it.
        debatem1 7y ago
        Ok. It isn't in permissive on Android, and there's a CTS test for it.
        temac 7y ago
        Android is typically the system that does not permit the workflow I was talking about. It does not make it necessarily the worst thing ever, simply it is an extremely different system than what GNU/Linux is. Now obviously it also uses Linux so it is useful to have some features even if they are (really) usable in one kind of system and not the other, but my point is that it would be better to have features usable by both, and we kind of know how to do it thanks to the pledge example: group the syscalls by theme, maintain the groups definition in (or at least shipped by) the kernel, done -- that virtually solves both the intermediate 3rd party library problem, and would have prevented that VDSO fail. Really the Linux kernel being so decoupled from userspace is one of the point that let it be so successful. Having a technology which drops or reduces that characteristic so much is by definition not going to make that technology used everywhere... Which is a big opportunity loss compared to practical solutions.

by raimue 7y ago

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.
      - naniwaduni 7y ago
        I'll believe "essentially no false positives" when people don't set SELinux enforcement to permissive and forget about it.
        debatem1 7y ago
        Ok. It isn't in permissive on Android, and there's a CTS test for it.
        temac 7y ago
        Android is typically the system that does not permit the workflow I was talking about. It does not make it necessarily the worst thing ever, simply it is an extremely different system than what GNU/Linux is. Now obviously it also uses Linux so it is useful to have some features even if they are (really) usable in one kind of system and not the other, but my point is that it would be better to have features usable by both, and we kind of know how to do it thanks to the pledge example: group the syscalls by theme, maintain the groups definition in (or at least shipped by) the kernel, done -- that virtually solves both the intermediate 3rd party library problem, and would have prevented that VDSO fail. Really the Linux kernel being so decoupled from userspace is one of the point that let it be so successful. Having a technology which drops or reduces that characteristic so much is by definition not going to make that technology used everywhere... Which is a big opportunity loss compared to practical solutions.