I apologize for my previous incomplete message. Premature send! Here is the full question:
Hello, I'm doing some experiments with the native servicemanager and I have a couple of questions on how SELinux policy might help harden my prototype, in particular regarding the dispatch of capabilities for system services. I am familiar with selinux_binder_transfer_binder() in hooks.c which is used in the kernel binder driver to check to see if a transfer between two sids is allowed by policy. This is kind of what I'm looking for, but I need to understand how to add more discernment regarding the allow/deny decision. Specifically, I would like to prevent certain apps from transferring system service capabilities to other apps. In other words, I want the context manager to be the ONLY way for an app to get the capability for a system service. I realize normal apps would just use context manager to get handles. This is fine; I am really looking at a theoretical corner case where a malicious app might try to bypass the new logic I'm introducing to servicemanager. In fact, I'm not even sure this scenario of one app passing a service handle to another app is possible since I can't seem to get such a demonstration working. Is policy the right place to do this? Or am I looking at some custom mods to the binder driver to block only certain transactions depending on the contents of the parcel? Thanks, Paul
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
