Hi Stephen, Separate SELinux policies for different users is really part of a bigger picture. As you know the AOSP/Google SELinux policy runs in enforcing, but most of the domains are set as permissive in the policy, so nothing is really enforced. I suspect that Google is doing this because they cannot guarantee that all apps will work under a properly enforcing policy. We have run into apps that don't work under a properly enforcing policy, and we have only sampled an extremely small subset of the apps out there. In our case, the personal space domains are set to be permissive, but the work/banking/branded spaces (which we call managed spaces) are fully enforcing. This way, if an app will not run in a managed space due to enforcing policy, it can always be run in the personal space. Since the managed spaces are managed by an IT department, even the apps allowed in those spaces are restricted. The IT department only allows apps that will work in a fully enforcing environment, all other apps must go to the personal space. BTW, all of our android service domains are fully enforcing, contrary to the AOSP/Google policy, so an app running in a managed space is truly running under an enforcing policy.
Of course, this doesn't answer your question, i.e., what happens if an app in the personal space roots the phone. Well, first of all, managed spaces file systems are encrypted with ecryptfs. Even root on the phone can not read the managed space files. Secondly, we separate spaces further using Linux kernel namespaces. We are not using full android stack containers like Cellrox. We have modified the dalvik vm, so that when an app is started for a space it is placed into a unique kernel namespace for that user. The namespace work is still under construction, hence the deadlines that are keeping me busy. Nonetheless, once complete, root in a personal space is not root on the phone, it is only root in that space. Additionally, root in the space will not be able to see processes, file systems, or network devices that belong to other spaces. All of this is done from a single instance of the Android middleware, we are not running multiple copies of Android. So, the theory is that the personal space can run in permissive. Apps in that space can go wild, but they can not affect apps in the managed spaces, nor can they see managed space data. Additionally, apps in a personal space can only root the space, they cannot root the phone. Apps in a work space take full advantage of an enforcing SELinux policy to stop them rooting the work space. I hope this explains why we have different SELinux policies for different users. BTW, we would love to get all our code into the AOSP and onto every phone, but this requires getting Google interested, which seems to be a challenge. Cheers, Chris. On Thu, Aug 14, 2014 at 8:10 AM, Stephen Smalley <[email protected]> wrote: > On 08/14/2014 05:25 AM, Pankaj Kushwaha wrote: > > Hi Chris, > > > > I created a new domain untrusted_app_owner.te and wrote some rules in it, > > and other one i.e. untrusted_app.te is same as it is. > > I made seinfo changes in ActivityManagerService, so that when app is > > started it checks whether user is 0 or any secondary user. > > > > If seinfo is 'default' and user is 0 it passes seinfo as 'default_owner' > > else it passes 'default'. Now in seapp_context I have written code such > > that if we get seinfo as 'deafult_owner' we give that a label > > 'untrusted_app_owner'. > > > > Now in this way if a run a app, say Google chrome in owner it gets > labelled > > as 'untrusted_app_owner' and if I run same app in any other user it gets > > labelled as 'untrusted_app' and hence follows rule as written in > > untrusted_app_owner.te and untrusted_app. > > > > I have almost done what I was willing to do. > > Now my question is, Is this approach fine ?? > > Also I wanted to know that what was the reason to modify code in > UserInfo, > > UserManager ,DevicePolicyManager and user xml files ? > > > > I got this when i grepped all running processes with 'chrome' - > > u:r:untrusted_app:s0 u10_a31 6484 6400 > com.android.chrome > > u:r:untrusted_app_owner:s0 u0_a31 8580 127 com.android.chrome > > Question for both of you: What is the benefit of running the same app in > different domains for different users? I can understanding wanting to > reinforce multi-user separation in Android, which is why we have the > levelFrom=user construct, but not separate domains. How would > untrusted_app and untrusted_app_owner differ? In your earlier email, > Chris, you said you might want stricter policy in the business space > than in the personal space, but a) that seems dangerous (e.g. I would be > more concerned about malware in the personal space escalating its > privileges and attacking the business space), and b) I don't really see > how/why the OS-level permissions needed by any regular app would really > differ regardless of personal vs business space, except that I would > want to separate them from each other. For the latter, levelFrom=user > would seem a better fit, as it offers a way to prevent the personal apps > from reading/writing files created by the business apps, although you > still need to do a lot of work at the middleware layer too. >
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
