You really went beyond the call of duty; I appreciate it. I did look at the AOSP code in the HEAD and saw that it was quite different. I spent yesterday afternoon debugging the SELinuxMMAC.java code. I instrumented the code to see what path it was taking and it turns out that your second bullet item seems to be the case. Not sure why yet, since the stanzas I began with were generated by setool. Some of our apps got the correct SEINFO value, and some fell through to "untrusted_app". (I'm a kernel/device driver/platform kind of guy, even in the Android realm, so the middleware is bit mysterious to me.) What worked (for this prototype anyway) was hand coding something like (doing this from memory)
<package name="com.foo.bar"> <allow-all/> <seinfo value="xyzzy"/> </package> with no signature, for our own internal applications. Other variations might work too, that's just what got me past the audits for now. This works for the time being until I can examine this a little closer. Thanks again, I'm impressed by your responsiveness. John Sloan -----Original Message----- From: Stephen Smalley [mailto:[email protected]] Sent: Tuesday, June 24, 2014 6:43 AM To: Sloan, John [GCS]; [email protected] Subject: Re: Gotchas in MMAC that leads to seinfo=default? On 06/23/2014 01:37 PM, Stephen Smalley wrote: > On 06/23/2014 01:23 PM, Sloan, John [GCS] wrote: >> Are there any known gotchas in the MMAC in CyanogenMod 10.2 that can >> lead to apps being assigned the default seinfo tag? >> >> >> >> I used setool to generate a whitelist for our apps that assign them >> to our own seinfo tag. >> >> I built and installed the mac_permissions.xml file. >> >> I verified that it contains the stanzas that setool generated. >> >> But some of our apps apps get our seinfo tag, and some get the default tag. >> >> Those that get the default tag end up in the untrusted_app context as >> expected. >> >> Perusing logcat I don't see any smoking gun between the ones that >> work and the ones that don't. >> >> Using setool to check APKs from both an app that works and one that >> does not work indicates both pass the policy. >> >> >> >> Thanks in advance, and apologies for the broad question. > > Unless they are using the SELinuxMMAC.java from our seandroid* > branches, you cannot assign a specific seinfo value to non-system > apps. There is a change uploaded to AOSP master to add that support > to AOSP, but it is still pending: > https://android-review.googlesource.com/#/c/80871/ I looked at the cm-10.2 SELinuxMMAC.java (please, next time - either attach the code in question or give a link to it when it is not part of our tree or AOSP), and it is an old version of our code that should support labeling third party apps, so I don't think that is the issue. Difficult to diagnose though without more information, e.g. a copy of your actual mac_permissions.xml file and the APKs or at least their manifests. Things to check: - Do you have multiple stanzas in your mac_permissions.xml that match the same apk, e.g. one that is signer-only and one that is signer+package name or that is package-name-only? - Maybe one of the APKs is mismatching on the allowed permission list for the matching signer/package stanza and falling out to the default stanza? - Maybe one of the APKs is specifying a specific process name or shared UID in its manifest and therefore is being launched in another process with a different seinfo? _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
