Uhh no? One of the biggest differences probably is that Android applications are heavily sandboxed:
> Applications are security principals. The main difference to traditional operating systems that run apps in the context of the logged-in user account is that Android apps are not considered to be fully authorized agents for user actions. In the traditional model typically implemented by server and desktop OS, there is often no need to even exploit the security boundary, because running malicious code with the full permissions of the main user is sufficient for abuse.
I just confirmed that Android uses a largely unmodified kernel, so in theory it should be possible to just implement whatever extra components make up the Android system. To your points:
- Sandboxing: Android accomplishes this by running each app in the context of a different UID.
- No root access: Like above, user-installable apps are given separate UIDs. The GUI and other system processes probably also get random UIDs. Probably very little of the Android system runs as UID 0. (However, I don't really believe that keeping the user from doing things as root is a valuable security feature, as long as the user is competent)
- Verified boot: There's nothing specific to Linux/Android about this, right? The bootloader handles checking the signature.
- Hardware-backed key store: Isn't this, as the name implies, "hardware"? So it should be OS-agnostic, right? Maybe Linux doesn't use it, and Android does, but someone just needs to write a driver for it (and maybe some bytecode implementation or whatever, if it's some secure enclave thing, which it seems to be).
- User profiles encrypted independently: I don't think the Linux kernel supports encrypting profiles, this is a userland feature of Android, and could therefore be ported to Linux.
> Applications are security principals. The main difference to traditional operating systems that run apps in the context of the logged-in user account is that Android apps are not considered to be fully authorized agents for user actions. In the traditional model typically implemented by server and desktop OS, there is often no need to even exploit the security boundary, because running malicious code with the full permissions of the main user is sufficient for abuse.
https://dl.acm.org/doi/fullHtml/10.1145/3448609
And then there's also:
- No root access (by default)
- Verified Boot
- Hardware-backed key store and hardware attestation
- User profiles are encrypted independently of each other
- …