On 08/05/2014 03:37 PM, Dinesh Garg wrote: > Hi, > I have couple of questions w.r.t. SEAndroid & Android Apps but before that > I would explain a little bit: > > Android apps are signed with a key depending upon apps category i.e. > platform app or system app or and so on. Depending upon that it would be > assigned a seinfo tag which would be utilized by zygote to assign a context > to app.
Just to note: In 4.4 and earlier, there was a limitation that all non-system apps would resolve against the default stanza of mac_permissions.xml regardless of signature. This restriction was removed in AOSP master by: https://android-review.googlesource.com/#/c/80871/ That was generally seen as a feature enhancement, and something long supported in our own seandroid* branches from the beginning. > Now if there is a vulnerability by which an application can be installed as > system, rogue app would be assigned seinfo as system or platform. Hence > rogue app can execute all privileged operations. If by "all privileged operations", you mean: a) Able to exercise any platform signature-only permissions, and b) Able to request and use any platform-defined UID, including system, and c) Able to run in any of the SELinux domains assigned to those UIDs by seapp_contexts, including system_app or platform_app, then yes. But note that the first two were there all along, even before SELinux, and that was by design in Android not an accident. Also note that this does not allow an app to run with full root privileges, although admittedly system UID is quite powerful in Android. > This is possible because if a user update a privileged app from Google play > or some other OEMs provided stores which would install app in /data. Yes, that's by design as I understand it. > First Q: is my above understanding correct? Yes, with the above clarifications. > Second Q: if yes, how can we mitigate this vulnerability? By making sure the signature validation logic is sound? Although the 3 variants of the Android master key vulnerability and now the Android fake ID vulnerability leave me distinctly uneasy. We could of course go back to only permitting use of the default stanza by non-system apps, although I think to make that complete we would also need to change seapp_contexts to specify seinfo=platform for all of the entries other than untrusted-app, but that would still allow (a) and (b) above; it would only block access to (c). > Third Q: is it possible that someone can replace the certificates those are > used to verify the platform apps? if yes, rogue person can replace the > verifying certs and install the modified apps which would get required > permissions to execute privileged operations. In theory, doing that would require modifying the /system partition, and if you can do that, you already have complete control of the device. Of greater concern are the kinds of vulnerabilities mentioned above. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
