Actually, requiring that current == proc->tsk might be too strict; current could perhaps be a different task/thread in the same thread group. It would suffice for them to have the same cred structure.
On Fri, Dec 19, 2014 at 1:34 PM, Stephen Smalley <[email protected]> wrote: > 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].
