On Tue, Aug 13, 2013 at 6:07 AM, Stephen Smalley <s...@tycho.nsa.gov> 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
