On 09/08/2015 05:01 PM, Jinlin Xu wrote:
> Hi Stephen,
> 
>  
> 
> Actually what I described here is exact what you said in the link:
> 
>  
> 
>                                                                               
>                                                                               
>                               
> 
> 
> http://marc.info/?l=seandroid-list&m=141150669811670&w=2.
> 
>  
> 
> - We could enable levelFrom=user for these apps*(<Added by me> such as
> system app, nfc)* too, thereby running
> 
> them with per-user levels like the other apps.  However, this would
> 
> break their interactions with system processes and resources unless we
> 
> annotate those system domains and types with which they interact with
> 
> mlstrustedsubject/object markings.
> 
>  
> 
> Thank you for above comments. Here is my implementation below:
> 
>  
> 
>  
> 
> Using isOwener attribute in seapp_contexts fileto make:
> 
>  
> 
> Owner user:  
> 
> system_app and  system_app_data_file have no category labeled. which is:
> 
> User=system isOwner=true seinfo=platform domain=system_app type=
> system_app_data_file
> 
>  
> 
> Secondary user:
> 
> system_app, and system_app_data_file have category labeled, which is:
> 
> User=system isOwner=false seinfo=platform domain=system_app type=
> system_app_data_file levelFrom=user
> 
>  
> 
> We also define system_app is mlstrustedsubject and system_app_data_file
>  is already mlstrustedobject. Therefore it is exact what you said in the
> above link.
> 
> We have already used this approach in the actual testing. It works perfect.
> 
>  
> 
> Please let me know if you any additional concerns.

What are you gaining by enabling levelFrom=user on secondary users if
you are making system_app mlstrustedsubject and leaving
system_app_data_file mlstrustedobject?  It won't restrict the system app
processes any further based on level, since you are making them
mlstrustedsubject (so you are actually weakening the defaults, as
system_app was not previously mlstrustedsubject and could not directly
open other app data files at other levels).  It won't further restrict
other apps' access to the system app data, since you are leaving it
mlstrustedobject.  So it seems to achieve nothing at all.

If you want to protect the system app data files from access by apps
running for other users, you need to not only add levelFrom=user but
also remove mlstrustedobject from system_app_data_file (or use a
different type that does not have mlstrustedobject for your secondary
system apps).  To do so without the ability to store the user's profile
photo, you need to amend the mls constraint to treat
system_app_data_file the same way as app_data_file.  That might be done
most easily by defining a new attribute, assigning it to both
app_data_file and system_app_data_file, and then rewriting the
constraints to use that new attribute.

If you want to prevent system app processes from opening files owned by
other users (levels) then you cannot make system_app a mlstrustedsubject.
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to 
[email protected].

Reply via email to