[Nexus 6  General] phhusson:
I'll try to answer to the various questions I've seen about difference between "standard Linux" root, and an Android root.

The basic idea is that if you think a desktop Linux is architecturally secure, then you're ****ing wrong. If Linux is not hit by virus is more because users are more educated, and softwares less used, thus less attacked. (Possibly they have less security holes as well).

Android is a real fortress compared to a desktop Linux.

Android uses different security features coming from Linux, but extended to a whole new domain.

First historically, is multi-user. On desktop Linux you can have multiple users, but they most likely represent physical user.

On Android, of course you have multi-user, but besides that, every single application is running as a different user!

(And multi physical user is implemented by having + 10.000 as user id, which means you're limited to 10k apps installed, possibly it has increased)

Next feature to be used in Android is SELinux.

Multi-user is still not totally secure, because the security is not centralized in one file, some permissions can't be expressed as simply multi-users.

For instance the permission "every user app can access their subfolder on the physical sdcard but not system apps" would be very annoying to express as multi-user, it would require ACL containing the whole user application range (ie 10k entries).

Another example is "every program can read the properties, but only some can write them". This can't be done with filesystem side permissions.

Obviously there are some other ways to handle it, and before SELinux was implemented, it was implemented in the property service itself.

But that means yet another place to look at for security constraints.

So here comes SELinux. Most security features are at the same place. Most important thing to know about SELinux is that it's a deny by-default policy.

If you want anything to be done in a program, you MUST allow it explicitly.

And then, next feature is dm-verity, or full-length verified boot.

This is meant to ensure that all the programs running the security decisions aren't modified by a virus.

Everything from display of bootlogo to SystemUI or Dialer are protected by a (manufacturer) public key.

There are a lot of different security features I'm missing for the sake of simplicity.

So, that's the Android security landscape, so let's discuss more precise topics:

- The difference between desktop Linux's sudo and an Android su: truth is you could use the same mechanisms on a modern desktop Linux on Android. (I'd say Android's su are a bit further in time than desktop Linux's, getting rid of setuid is fairly new to desktop Linux with machinectl, while it has been in Android since 4.3). The difference lies in the libraries used. Developers on a desktop/server Linux are more confortable with all the tools available, and can more easily do tools. On Android, not so many people have proper knowledge of all the frameworks interferring. And Android has many security frameworks interfering.

- As for manufacturer/Google-locking: Google doesn't want to reduce root usage. Or rather, it wants to reduce root usage, by implementing functions previously only usable by root! cf the Android Pay's guy comment about root. What they mostly care about, is not to have half of Android zombie devices. Every OS conceptor has Windows XP in mind and wants to avoid doing that again. Of course Google cares about its ads, but they definitely don't seem to be activist about it. You've got the whole adblock suite available on Play Store!

Some informations about "Google-locking":

- ALL chromebooks, without a single exceptions can be reflashed with whatever OS suits you.

And when I say it can be reflashed, the documentation of how to do that is on Google's website!

And this, while being (one of) the most secure consumer OS available.

- Google documents (and implements on Nexus-es... I think/hope) what a verified boot should look like: http://source.android.com/devices/tech/security/verifiedboot/verified-boot.html

what is very interesting here, is that it describes how a custom ROM can have its own keystore.

This means Google documents and implements ways of having custom ROMs as secure as original manufacturer ROM.

We are no longer speaking of just allowing users to flash anything. It is allowing users to flash anything... and to keep secure!

If a user want to have pure AOSP build, without Google Apps, then he can, and it can still be secure!

There is one big difference between Android and desktop Linux which makes things harder, I haven't mentioned yet (and which doesn't really belong in this precise thread)

Manufacturers are allowed to do mostly what they want on the boot system, and an SU is tied to the boot system (even more since SELinux). Good news is that boot systems are mostly converging, and having a code working on many devices is getting easier.

But having a 100% devices coverage will be impossible.