Android 4.2 to include SE Linux and other security features | Hacker News Reader

Android 4.2 to include SE Linux and other security features

androidpolice.com

145 pointsmtgx23 comments

Russell Coker has had a SELinux enabled box online for many years now where he allows people to log on as root. http://www.coker.com.au/selinux/

It is somehow immensely amusing to me to see 'permission denied' errors when I'm quite clearly logged on as root.

Try to get any information at all about /home/bofh while you're logged in.

Yes, most people have no idea of the things that are possible with SELinux. It's really amazing.

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.

What's abnormal about the way Android uses the Unix user and permissions model?

For a start, it uses a special group to denote 'this process can access the internet', requiring a kernel patch: http://elinux.org/Android_Security#Paranoid_network-ing

Don't they make each application you use run with it's own user?

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.

Anyone else negatively impacted by this?

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.

Can I disable it? It seems like in most deployments that is exactly what happens to SELinux.

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.

https://www.nsa.gov/research/selinux/

[1] It’s also because it unfortunately isn’t actually used by most desktop applications, with some exceptions, like Chromium.

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.

Laziness might be justified sometimes, but you may as well call it what it is.

You shouldn't feel embarrassed, SELinux is so fine-grained that a proper configuration is very difficult to attain.

Directly from the article: "The other key piece of information to get from the string file is that this is an optional mode..."

Surely vendors could choose to make it optional unless you have the correct permissions, could they not?

It's only disabled by clueless admins. The security gain from the tiny amount of work it takes to get working is massive.

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.

That was ages ago at least with Fedora. I used to disable it as well, but I stopped doing this about 3 years ago.

Yes I tend to disable it.

It's the Verified By Visa of OS security.

Reply on news.ycombinator.com