Hi Stephen, Thank you for your comments. We will consider your suggestion.
Regards and thanks, Jinlin -----Original Message----- From: Stephen Smalley [mailto:[email protected]] Sent: Wednesday, September 09, 2015 6:04 AM To: Jinlin Xu Cc: [email protected]; Dingbang Xu Subject: Re: possible approach for levelFrom=user 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].
