3 ms·

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 i

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
        I don't want to segregate Android from other Linux systems or anything like that, but I was just making the remark that this is a (very) different system compared to classic GNU/Linux distros. With different actors at different points of the lifecycle and so over. Like in practice: as an end-user I can't update the kernel on my Android phone; which is a huge shame IMO (it could as well use the NT kernel as far as I'm concerned, it would change nothing about my practical freedoms) Also I was never really talking about SELinux because I don't know much about it -- the article was initially talking about seccomp and so was I. If SELinux groups syscalls, then that's good and way better than seccomp on that topic in my opinion. BUT: I'm not a fan about having "security policies" potentially separated from applications and potentially written by yet another party -- at least not on that level -- in most case that makes no sense IMO; only the applications (1) authors know or are the most efficient to specify what is needed; and if furthers restrictions are wanted they ought to be tunable by the end user with a nice GUI and a few on/off controls. About libraries evolving under your feet: if the library are not insane, and the groups of syscalls (or "subsyscalls" if needed, like the ioctl case) are good enough, then you shall avoid virtually all problems. At least, for sure, you will avoid trivial problems like the VDSO one. EDIT (1): "application" in the GNU/Linux sense. Android applications are completely different beasts.

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
      I don't want to segregate Android from other Linux systems or anything like that, but I was just making the remark that this is a (very) different system compared to classic GNU/Linux distros. With different actors at different points of the lifecycle and so over. Like in practice: as an end-user I can't update the kernel on my Android phone; which is a huge shame IMO (it could as well use the NT kernel as far as I'm concerned, it would change nothing about my practical freedoms) Also I was never really talking about SELinux because I don't know much about it -- the article was initially talking about seccomp and so was I. If SELinux groups syscalls, then that's good and way better than seccomp on that topic in my opinion. BUT: I'm not a fan about having "security policies" potentially separated from applications and potentially written by yet another party -- at least not on that level -- in most case that makes no sense IMO; only the applications (1) authors know or are the most efficient to specify what is needed; and if furthers restrictions are wanted they ought to be tunable by the end user with a nice GUI and a few on/off controls. About libraries evolving under your feet: if the library are not insane, and the groups of syscalls (or "subsyscalls" if needed, like the ioctl case) are good enough, then you shall avoid virtually all problems. At least, for sure, you will avoid trivial problems like the VDSO one. EDIT (1): "application" in the GNU/Linux sense. Android applications are completely different beasts.