4 ms·

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 comp

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.
        debatem1 7y ago
        I'm confused. First, Android is a Linux system, and underneath the app framework is really a pretty normal one. So I'm not sure what distinction you're drawing here. Second, the grouping of related syscalls is something SELinux already does-- open, for example, doesn't care if you open() or openat(). That grouping lives in the kernel as well. So that would appear to do what you wanted? Third, pledge does not do what you described. Although it restricts access to syscalls, the more important thing is how it restricts the behavior of those syscalls. That policy is something you could write in SELinux, but not in seccomp. And of course, pledge isn't capable of doing the useful things SELinux and seccomp can, like forbidding certain ioctls but allowing others. Fourth, SELinux was not bitten by the VDSO issue. Fifth, both pledge and SELinux get hit by the third party library issue in exactly the same way: you have a policy which was sufficient under the old version of the library, but something has changed and now they need something else. The only difference is that with SELinux the person who might know that the third party library had changed is also responsible for the policy, where with pledges you don't have that visibility. Finally, I don't know what you mean with your last paragraph at all. The kernel has a contract with userspace and kernel developers broke it, is that what you mean by decoupling here? I'm not sure it was a good thing, and the kernel folks seem to agree...

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.
      - debatem1 7y ago
        I'm confused. First, Android is a Linux system, and underneath the app framework is really a pretty normal one. So I'm not sure what distinction you're drawing here. Second, the grouping of related syscalls is something SELinux already does-- open, for example, doesn't care if you open() or openat(). That grouping lives in the kernel as well. So that would appear to do what you wanted? Third, pledge does not do what you described. Although it restricts access to syscalls, the more important thing is how it restricts the behavior of those syscalls. That policy is something you could write in SELinux, but not in seccomp. And of course, pledge isn't capable of doing the useful things SELinux and seccomp can, like forbidding certain ioctls but allowing others. Fourth, SELinux was not bitten by the VDSO issue. Fifth, both pledge and SELinux get hit by the third party library issue in exactly the same way: you have a policy which was sufficient under the old version of the library, but something has changed and now they need something else. The only difference is that with SELinux the person who might know that the third party library had changed is also responsible for the policy, where with pledges you don't have that visibility. Finally, I don't know what you mean with your last paragraph at all. The kernel has a contract with userspace and kernel developers broke it, is that what you mean by decoupling here? I'm not sure it was a good thing, and the kernel folks seem to agree...