On Feb 10, 12:01 am, dh <[email protected]> wrote: > Hi, > > > I had thought about before too. From the implementation point of view, > > you need someone to send you either a binder or handler (like > > invitation) to be able to create a kernel level reference (numbered > > locally), which you can then use to start transaction with. As the > > reference number is created locally, there's no point of guessing or > > forging, because if you don't have a local reference, the kernel will > > simply reject it. From that perspective, it's probably secure. > > That's my point; if I'm wrong, point it out. > > /dev/binder is world-writeable on the filesystem. Is it possible to forge > an IPC transaction (the id/ref number of the remote node, transaction code > which is simply an integer, the parcel data, binder flags, ...) and send it > directly from application A to application B, thus circumventing the > service manager.
Okay, need to clarify a bit. First of all, I recall some where in the android documentation, it describes the binder communication is based on some kinda shared secret. I think it's not quite right, and often time words like that can trigger alarms for a lot of security analysts... :) First, the service manager does very little things and minimum checks. All it does it is storing any incoming object handle and name pairs so others can query handles based on name. It only checks if a registering (add service) request is coming from a list of known uids, if not it simply rejects it. Anyone can query a handle using a a name. The service manager doesn't put any restrictions on it, and I believe it's up to the actual service provider to check the permissions and so on when they actually receive a request. Think the service manager as a DNS server. In IP connections, for two hosts to take to each other, you need a TCP/ IP connection and a socket (port number, like 80). In terms of binder IPC, you need a connection between two processes and you need an object handle to identify which service you are talking to. The kernel sets up the connection between two processes and creates object handles (like sockets) for both parties to talk to each other. Again, like TCP connects, you can't simply inject packets to any existing connections to forge traffic, you need to be in the loop to be able to generate legitimate data. In theory you shouldn't need the service manager to set up an IPC connection between two processes. But the service provider doesn't know what process is going to use the service only until the client process starts making requests, which leaves the service provider no choice but to publish its service (i.e. object handle) to a known existing party - the service manager in this case, so later on clients can get it from there. So you see, you can't send anything from process A to B without a proper connection. On the other hand, once the connection is set up between A and B, communications happen directly between A and B - the service manager is not involved at all. These are just my understanding of how the existing binder system works. Hope it could clear some of your concerns. -- unsubscribe: [email protected] website: http://groups.google.com/group/android-kernel
