On Tue, 2012-09-25 at 20:24 -0400, Joshua Brindle wrote:
> This isn't something I think we should add to the upstream policy but I
> think it deserves some discussion. Below is a policy for chrome, you'll
> notice some pretty horrible things about it, namely mlstrustedsubject
> and isolated_app rules.
>
> How do we plan on dealing with apps like this? I'm not exactly sure what
> is going on, the denials aren't terribly helpful (they are attached for
> the curious) but it is clear chrome does some pretty terrible things...
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.
> type chrome, domain, mlstrustedsubject;
>
> app_domain(chrome)
> net_domain(chrome)
>
> allow chrome isolated_app:dir { read search open };
> allow chrome isolated_app:file { read getattr open };
> allow chrome isolated_app:unix_stream_socket { read write };
> allow chrome system_data_file:file { execute open };
>
> allow isolated_app chrome:unix_stream_socket { read write };
> allow isolated_app system_data_file:file { open execute };
--
Stephen Smalley
National Security Agency
--
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.
