I simultaneously welcome and fear this development.
It's a great move for security, as a well-configured SELinux deploy can provide much finer-grained access control than standard Unix permissions (although, given that Android uses the Unix user & permission model a bit abnormally, I don't know if it will bring benefit over that or not).
OTOH, for locked devices, it gives vendors more tools to prevent rooting.
Yes. I guess that's what the grandparent means. I don't find it abnormal, it's a very good practice - create user accounts for public-facing processes and give them as minimal rights as possible. Still, the possibility to somehow break out and gain root exists.
It is unusual in that usually applications meant to be consumed locally by the owner of the device are not considered "public-facing". It is something usually done with servers or daemons, not web browsers and text editors.
Yeah, I figured that is what was being referred to...it didn't strike me as abnormal though, but I guess it is. In practice this hasn't caused me any problems while developing on Android.
Didn't intend to imply anything negative by "abnormal". It just isn't the "traditional" way to use processes for a user-facing, semi-desktop system. But given Android's special-purpose, single-user nature, it is a perfectly logical system (and quite clever, really). It just isn't the way users are used e.g. on my Fedora laptop.
I’m using Fedora in enforcing mode, and so are probably most Fedora users. SELinux is usually completely transparent on desktop[1]. Of course it can sometimes cause some issues you might be unprepared for.
The most recent one I can remember was configuring Postfix to perform local delivery to ~/.local-mail/inbox. I had to manually change security context for that directory. Or linking /var/www/foo to ~/foo is an example of something that you might expect to work, but would be blocked by SELinux.
But those are not the kind of things you would do on Android anyway. They use SELinux to strengthen the security framework they already have in place. SELinux is just the last line of defence for implementation bugs and things they might have missed. It would be completely unintrusive.
The NSA presentation is worth watching, they go through various Android exploits that could have been prevented by the policy they developed, without actually targeting those specific exploits.
i am embarrassed to say this but rather than configure SELinux to do those little things - like local mail delivery or open a new socket for httpd - i tend to just disable it. i'll chalk it up to a usability problem on their part and not laziness to learn it on mine.
i'm familiar with it, i've written some policies in it, i remember when it was introduced. that said ... i don't use it.
Instead of disabling it, consider putting it into permissive mode. It logs violations but doesn't enforce any rules. It's a good way to get a feel for what it's doing. You can tweak the rules, view the logs, tweak some more, and work up to a tight policy before enabling.
Also, if you disable it, re-enabling requires that you relabel all of your files and reboot the system; the relabel process can take an impressive amount of time.
Switching between eforcing and permissive can be done on the fly with the setenforce command, no reboot required.
I do think that laziness is a virtue in a sysadmin when properly applied, but using selinux is in your best interest.
Or admins who don't want to spend a day or two to learn about selinux and implications of adding it, then a couple more days to actually implementing proper policy for the company and deal with all the things you did not expect at first.
In reality it's not a tiny amount of work unless you're dealing with a single server. It's not a small amount of information to learn either. And it can have pretty bad effects if you happen to cut off your access by accident. So no, can't agree with the clueless admins comment.
