> I'd argue that permissions aren't really enforced by binder, just binder is used to talk to the endpoints that enforce permissions. Binder has no interaction with SELinux outside the policy requirements to allow apps to open it's device nodes - there's no interaction in the kernel code at all [0]. It's just an opaque data blob IPC mechanism, not tagging payloads with capabilities or similar in-kernel.
I'm going to describe some flows so you can have a perspective on what's going on. I'm describing them as I remember when I worked with this stuff.
First, you have to know about SEAndroid which is a thing built on top of SELinux. It doesn't add anything new from a kernel perspective but there's a whole 'firmware image build-time framework' to _legislate_/declare permissions about all sensitive stuff on the system. Like, you want to add a new daemon to the system? Maybe this daemon will serve some AIDL (such daemon is called a service)? Oh, then you should declare its SELinux stuff, like "it's a daemon", "it should have access to sockets/whatever" and "it will serve such and such AIDL interfaces" and so on. You should state the things it should have access to. The important part is that the SEAndroid stuff has 'Binder services' as a first class citizen, much like a fs path, socket or anything else SELinux is capable of legislating about (even though the kernel and kernel's binder knows nothing about binder services from an SELinux perspective). A good part of these policies don't talk about vanilla Linux stuff (like processes, files, sockets, etc.) but are about _services_ from "binder realm" - the kernel doesn't know about and ignores them. During the system image build process these policies are "compiled" and put somewhere on a filesystem.
When Android boots, after all the device-mapper mess (which, as most things, is a subject on its own) eventually the "base" filesystems are mounted (this mess comes in part from Project Treble). At this point there's no SELinux stuff loaded (which means, IIRC the SELinux status from the kernel is "off"/insecure/whatever). Then comes the time when the SEAndroid/SELinux policies are to be loaded. A system process looks up and loads the SELinux blobs generated during the system's image build process, and then enables SELinux.
Ok, now a flow from runtime:
You have process A, which in this example will be on the client role, and process B which will be the server. Process A comes from a program A which is a plain ELF binary on the filesystem. Same for process B. The SEAndroid policies loaded during boot define the SELinux contexts associated with process A and B. Program's B context includes the list of AIDL interfaces/services it implements (or serves). And program's A context includes an statement that it should have access to such and such AIDL services (it states nothing about program B or others who implement the AIDL services).
Every binder driver device is exposed to userspace through the /dev fs and they each need to have an associated _service manager_ process. When I worked with these there were 3 binder devices, and so 3 associated service managers. Originially there was just 1 binder. So process A needs to have access to, say /dev/binder, and this is enforced with vanilla Linux acccess controls. Same for process B on this part. Process A tries to establish communication with whatever process is implementing the AIDL service it's trying to talk to (process B) (services have a string name, it's a binder thing). This attempt actually ends up on the binder's service manager, which asks the kernel's SELinux policy 'Can this process A here access that AIDL interface?'. The kernel doesn't know about AIDL interfaces, but the SELinux policy blobs downloaded into it earlier encode this info in such a way that such questions can be asked and answered. If so, it awakes/starts process B and communication goes on.
As an addendum, binder supports transporting file descriptors and that's what I meant by true capabilities. That has lots of implications and caveats given it's going on a Linux-based system but that's another conversation...
> And native code does have access to every service on the device
No, it dependes on which process, or more specifically, which SELinux context the process running that code has been attributed to.
> At an extreme level, the java code is run in the same memory address space as any native code, there's no protection from that
Yes, on the level this conversation is concerned about, it doesn't matter what you program is doing, if it's a Java thing, python, web browser, if it's a code dynamically linked into your process from a shared library object - what matters most is that it ends up calling syscalls and that each process has an identity from the SELinux perspective inside the kernel (so the SELinux subsystem inside the kernel knows which process is calling a given syscall).
> Perhaps you think I'm including all the stuff people associate with modern "Desktop Linux"? Like X11 and/or wayland? Or the entire FHS?
My comment about this part would be that libc is... not related at all. It's importance comes from 'Oh, this is C/C++ code so it doesn't actually issue syscalls, it does all that though a libc because, well, this is C and Unix'. On this abstraction level I would put it as just an implementation detail as apps being programmed in Java.
> the system described in the post is mostly about taking away
I agree.
The hard part is, as usual, on the details. How do you take away stuff so that you still end up with an usable general purpose OS? That's definitely not easy, specially if you want to make it in a proper way, without hacking things up.
For example, suppose you make the decision to use the Linux kernel, which is a good one - you get driver support, networking, filesystems, and all the good stuff and general primitives for a common OS of today.. Given that what one wants is to remove stuff, in order to make that secure (which is requirement) you'd need to isolate and block everything because on Linux everything is accessible to a process by default, and the common primitives for control are very basic - you'd have to do a _lot_ of work in userspace to block it. It would contaminate your userspace architecture with details and stuff. And then you'd probably end up needing something to make the userspace parts able to communicate with each other, like Binder on Androids case (see my other comment in this thread).
Android blocks most of Linux syscalls with seccomp. They make heavy usage of SELinux.
Binder is not just a simple IPC system. It requires userspace parts which aren't even the parties who are talking through IPC. Like you said it has lots of performance optimizations, and that requires it hooking up to a number of kernel subsystems. At the beginning it was met with a lot of resistance from kernel maintarners when tried to be merged.
Why did Google came up with it? When talking about the 'Android sandbox' people usually talk about how Android gives each app an different uid/gid. But that's just the beginning of the story. It wasn't enough for sandboxing needs since the beginning. Thats why they took the binder idea from BeOS and used on Android.
Since then Google has blocked everything. Native code is needed on any practical system, but today's native code has access mostly to nothing, just the common needs to run (like libc which is used due backward compatibility). The proper way to get something is through Binder (and even that is fine-grained controlled on a per process basis).
Linux and Unixes in general don't implement true capabilities. Android does through Binder, but since Binder lives “inside Linux” everything else has to be blocked to make these capabilities useful.
> Some hardware access is marshalled through userspace daemons
Most of stuff are, at least initially, orchestrated through userspace software - daemons like you said, but mostly HALs (which are also daemons).
The main takeaway is that binder is _the core_ of Android userspace. It's tightly integrated with SELinux and everything passes through it at some point. Permissions are enforced through it. In the end, the whole “binder subsystem” is architectured like a Microkernel system.
Not sure if this is what you meant, but I'd like to expand a little bit on it.
- This API should be programming language agnostic (like, with a well defined ABI). Ideally an IPC based one, with a well defined wire format and protocols.
- Not a singular API, but an “API system” with extensibility taken into account from the beginning (with things like versioning). It should be able to support arbitrary new API definitions so that other apps could consume, and also produce.
- Such an API system should be used by the OS itself too, of course. So the OS would have the resulting benefits and the whole system would be more uniform.
Just want to point out that starting an OS from scratch, even if reusing an existing kernel, is a monstrous epic.
I find it difficult that one would be able to just use existing kernels like Linux without some considerable changes to support a more secure userspace (which seems like a requirement in order to do wild new things).
Because Linux, the kernel, as well as other Unixes, don't have the right abstractions to easily build these. And there's all the old cruft.
Just look at what Android had to do to implement a secure platform with somewhat of a well defined non-1980's OS API - it basically removed the Unix part of the OS and built a Microkernel-like thing on top of it.
Driver support would be a very important part though.
> Could I theoretically use it in my linux program just like any other IPC mechanism?
Yes, absolutely.
However, binder is implemented as a kernel module not enabled by default, so it depends on the build time configuration of your system's target kernel (eg., your distro's).
That given, it's important to note that the binder driver/module is just one piece of a greater framework and it's raw IPC features aren't as simple to use as SysV or POSIX's. For example, it requires a userspace process called context (or service) manager. Android has 3 different binder device instances and it builds a big framework on top of them wiring things like an interface definition language (AIDL), a set of libraries and SELinux permissions.
Also, as mentioned in the patch's message, it's important to highlight that binder is a core component of Android. Its usage is so widespread that, to me, it kinda makes Android architecture very akin to a microkernel-based system.
> One thing though, you focus a lot on syscalls, but I think the challenge in recent years has been to find new ways to have kernel <-> userspace interactions _outside_ of syscall, which are cumbersome to use, rigid in structure, and practically speaking, there are only so many entries you can store in an IDT.
Today there is another option for doing the kernel-userspace communication: using an io_uring like interface. Yes, it's a syscall, but it's one with enough extensibility and performance characteristics. It's extensible because it's close to an IPC with the kernel (and it could be changed to be a new IPC mechanism for process-to-process communication if it isn't already). And it's performant because it's based in shared memory and is assyncronous by default.
Besides, wouldn't that be exactly like our current physics? (Where we reduce until we find something fundamental like “electric charge just is and has this properties”, similarly for Quantum fields and the like -- and then how that composes and interacts with other fundamentals is the whole business.)
Fuchsia has an http client component [0][1] which is part of the platform and, given Fuchsia's component architecture, it's accessed through a message-passing protocol [2] which is programming language agnostic.
They are doing this to solve the chicken-and-egg problem of booting the adoption of Fuchsia. Without Android (ie. Linux) support, there's no way to pull off Fuchsia.
https://en.wikipedia.org/wiki/Letters_of_last_resort#:~:text...