A few of you mentioned that you're running the gapps with the release_app or untrusted_app domain. How are you guys handling OTA updates? The GoogleServicesFramework.apk performs this functionality and needs to be able to read/write and create dirs and files in /cache. Presently, we only allow platform_app and media_app the ability to read/write to the /cache partition. Are you guys using other means to deliver OTAs? Did you change policy to allow release_app or untrusted_app access to the /cache partition?
On Wed, Aug 14, 2013 at 8:08 AM, Tai Nguyen (tainguye) <[email protected]>wrote: > OEM resigns a few apk ( I think Craig listed them). The rest are not > resigned so they can be updated via play store. > > Some permission have signature protections which will be checked during > installation time (at least for now) before it is granted. > > Best regards, > > From: William Roberts <[email protected]> > Date: Tuesday, August 13, 2013 9:43 PM > To: Stephen Smalley <[email protected]> > Cc: Tai Nguyen <[email protected]>, rpcraig <[email protected]>, " > [email protected]" <[email protected]> > Subject: Re: gapps domain > > > > > On Tue, Aug 13, 2013 at 6:07 AM, Stephen Smalley <[email protected]>wrote: > >> On 08/12/2013 10:22 AM, William Roberts wrote: >> > Since we are building outside of an OEMs tree, I would imagine you're >> not >> > using their private key to sign your applications that should be >> platform, >> > etc (Except for the NSA ;-) ). I would imagine that everyone here made >> an >> > additional entry in seapp_contexts and mac_perms.xml? However, IMO if >> I'm >> > not the one holding the key it should go into untrusted_app. I can't >> > remember if when I was at Samsung if we resigned the APK's or not, I am >> > pretty sure we did not. >> > >> > As far as permissions go, its non-system uid which means its capability >> set >> > is NULL, so at most it can/would use hidden APIs, etc. And if the keys >> > aren't matching, it should get through signature based Android >> permission >> > checks, so whats the real reasoning behind either platform or release >> > domain? >> >> As I recall, they do require some kernel-level permissions that we do >> not grant to untrusted_app in our policy. > > > Is that permission tied to a signature check of sorts, or is it > arbitrary? UID makes > it clear, but some things are a bit trickier. If it's tied to a > permission not tied to > a build time key, then it should move to untrusted app. I don't think OEMs > re-sign > gapps. > > >> And they likely expect to >> share files and communicate freely without the MLS restrictions. >> > > That I could see, but for the general Android ecosystem, those are a bit > too > restrictive. I think using multi-user framework for isolation will be > much more > palatable. > > > -- > Respectfully, > > William C Roberts > >
