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.
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.