48 ms·

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

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.

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.