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. Does the binder implementation perform security checks for such things? If I get you right, the binder module in the kernel DOES do these security checks?! > The first priority of my project was to implement a version that can > be used as a drop replacement, well as much as possible. So logic > mentioned above mostly applies to my implementation too, but I'd > certainly consider those security aspects along the way. > I see that you focused on concurrency and performance. I was just wondering about the security things of binder in earlier work. If the default implementation is secure, then fine. If there are some vulnerabilities, maybe that's interesting for your project. Cheers, David -- unsubscribe: [email protected] website: http://groups.google.com/group/android-kernel
