Stephen Smalley wrote:
On Tue, 2012-09-25 at 20:24 -0400, Joshua Brindle wrote:
<snip>
Actually, this indicates that chrome is using an isolated service
component (android:isolatedProcess="true"), which was introduced in
4.1/JB. That is a good thing, not a terrible thing. The problem lies
in how we are labeling isolated processes presently (the user=_isolated
entry in seapp_contexts). Since we are presently enabling
levelFromUid=true for both _app and _isolated, we are forcing a
situation where it has to cross levels in order to interact with the
isolated service component. Maybe we shouldn't be enabling levelFromUid
for both, or somehow derive the one from the other (not sure how though
- we don't have sufficient information at that point to correlate them I
think). Evidently chrome tries to read /proc/pid/task/tid/stat for the
isolated service for some reason, and they communicate with one another
using a local socket. That seems reasonable. The system_data_file
denials are from trying to execute an app-private shared object, so that
also seems reasonable.
silly me, I just assumed as a Google app it was doing things other apps
shouldn't do...
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.
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?
--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to majord...@tycho.nsa.gov with
the words "unsubscribe seandroid-list" without quotes as the message.
