This is basically getting at that alternative runtimes must obey the platform's security sandboxing, thus not introduce security holes in the device. This is very easy to do, by things like loading code into the runtime environment that has more permissions than the app the user installed claims to.
On Thu, Aug 26, 2010 at 4:16 AM, Vincent Kuo <[email protected]> wrote: > Hi all, > > My colleagues and I have studied the Android Compatibility Definition > Document recently and we all are confused by some descriptions listed > in 10.4 Alternate Execute Environments part. In this section, we have > that > > 1. “Alternate runtimes MUST NOT launch with, grant, or be granted > access to the sandboxes corresponding to other Android applications”, > > 2.“Alternate runtimes MUST NOT be launched with, be granted, or grant > to other applications any privileges of the superuser (root), or of > any other user ID.”, and > > 3.“The .apk files of alternate runtimes […] MUST be signed with a key > distinct from the key used to sign other applications included with > the device implementation.”. > > We are having the conception that alternate runtimes and installed > apps using an alternate runtime won’t share user id with other Android > applications based on the above statements but this conjecture seems > to be contradicted to the following statement listed in this section > as well, > > “Alternate runtimes and installed applications using an alternate > runtime MUST NOT reuse the sandbox of any other app installed on the > device, except through the standard Android mechanisms of shared user > ID and signing certificate.” > > We try to interpret this as alternate runtimes can only use > sharedUserId to acquire certain uid used to be used by some > applications not using an alternate runtime installed on device but > not anymore, but what exactly does the “reuse the sandbox” mean? > > Could anyone please help to explain or give us a scenario or a > possible prohibited use case? Any reply or suggestion would be > extremely helpful. Thanks. > > > Regards, > Vincent > > -- > You received this message because you are subscribed to the Google Groups > "Android Security Discussions" group. > To post to this group, send email to > [email protected]. > To unsubscribe from this group, send email to > [email protected]<android-security-discuss%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/android-security-discuss?hl=en. > > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
