When I originally analyzed the binder driver for SE for Android, I noticed that they have a layer of indirection known as a "binder process" or binder_proc that is set up when a process opens /dev/binder and is associated with that open file. A pointer to the opening task is saved in the tsk field of that binder_proc structure when /dev/binder is opened. Subsequently, they use that tsk field for binder transactions made using that open file, so for example, the sender euid is taken from that tsk's cred structure. So for our SELinux binder call check, I also use the SID/context from that tsk's cred structure as the source context. However, this leaves open the possibility that a process could open /dev/binder, pass the open file descriptor to another process via local socket or via binder itself, and then that other process could call ioctl() on that open file descriptor and effectively impersonate the original opening process. I was unclear as to whether this was an intentional feature of binder or just an implementation artifact. So I also implemented the binder impersonate check to ensure that if the process performing the binder transaction has a different SID/context than the opener, we can control that via policy. As we have not seen impersonate denials, I assume that no one is using this and I am not sure that it would even work in practice; other aspects of the binder driver may assume that the sender task is always the same as the one saved in the binder_proc. So we are presently just ensuring that this never happens by not allowing it in policy. Would likely make sense to check that current == proc->tsk in the binder driver on the ioctl calls if that is in fact a requirement, and then we could dispense with the check. That would also close the possibility of sender euid impersonation, which our check does not address.
On Fri, Dec 19, 2014 at 12:04 PM, William Roberts <[email protected]> wrote: > In the binder driver are the checks on impersonating credentials over the > interface. Has this ever been tested and if so how? I have yet to see any > use, but I am wondering how to excercise its functionality. I took a peek at > the Java layer binder classes, and didn't see anything. Is this only exposed > in the C api's, or do I need to do the ioctl myself. > > -- > Respectfully, > > William C Roberts > > > _______________________________________________ > Seandroid-list mailing list > [email protected] > To unsubscribe, send email to [email protected]. > To get help, send an email containing "help" to > [email protected]. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
