Yes, I'd like to know something about the security of the binder implementation. Can I just forge an IPC by talking to /dev/binder?
-Earlence On Feb 9, 2:01 pm, dh <david.her...@uni-ulm.de> 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. > > 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: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel
