On Thu, 2012-09-27 at 09:34 -0400, Stephen Smalley wrote: > On Thu, 2012-09-27 at 06:57 -0400, Joshua Brindle wrote: > > u:r:chrome:s0:c57,c256 u0_a57 9564 667 com.android.chrome > > u:r:isolated_app:s0:c2,c256 u0_i2 10257 667 > > com.android.chrome:sandboxed_process0 > > > > So the sandboxed_process is part of the chrome package, so presumably it > > has seinfo set to what the main chrome process would. Is there something > > we could do with that? Since user= has the highest precedence removing > > it and letting both the main app and isolated app match an seinfo > > probably wouldn't work, and would still have different UID's... > > > > If isolated app didn't have levelFromUid=true they wouldn't be isolated > > from each other, at a MAC level, which seems non-ideal. > > I think the levelFromUid logic is likely wrong for isolated UIDs anyway; > if we truly want it, then it needs to distinguish regular app UIDs from > isolated UIDs. We could set a third category in the set, c512 for > regular app UIDs and c513 for isolated ones ;) > > I have some doubts about whether levelFromUid=true is going to get used > for anything in production devices; it breaks the current assumptions > about apps being able to share files if they want to do so and thus will > run afoul of compatibility. I suspect that we are more likely to see > usage of explicit level= labeling for well-defined use cases (e.g. > personal vs business, unclass vs class, per-container levels, etc). > > > You've probably worked through this already but I haven't looked at the > > isolated app code yet. In > > ActivityManagerService.java:newProcessRecordLocked it looks like it > > searches for a new UID at runtime, so it isn't even stable across app > > reloads... drat. > > > > Would it be possible for the PackageManager to pass down the App's UID > > as part of the seinfo string? Then, instead of using the effective UID > > for the level we use the App UID? > > I'm sure it is possible, but I'm not sure it is useful. > The semantics of isolated services IIUC are: > - They don't get any Android permissions (as per > checkComponentPermission and checkUriPermission). > - They can't invoke any other component (as per startActivity and > others). > - As they run in their own unique UID, they have no access to private > files of any app (not even the ones of the owning package) unless those > files are made world-accessible or passed directly as open files to the > service. > > So it doesn't truly make sense to group them into the same level as the > app. > > I wonder if we shouldn't just disable levelFromUid.
For now I would recommend at least this patch, to disable levelFromUid for isolated services. You'll still need to add allow rules for the interactions with the app domain, but you shouldn't need mlstrustedsubject. -- Stephen Smalley National Security Agency
diff --git a/seapp_contexts b/seapp_contexts index 25d7316..f63da7c 100644 --- a/seapp_contexts +++ b/seapp_contexts @@ -41,4 +41,4 @@ user=_app seinfo=shared domain=shared_app type=platform_app_data_file user=_app seinfo=media domain=media_app type=platform_app_data_file user=_app seinfo=release domain=release_app type=platform_app_data_file user=_app seinfo=release name=com.android.browser domain=browser_app type=platform_app_data_file -user=_isolated domain=isolated_app levelFromUid=true +user=_isolated domain=isolated_app
