>
>
> This was true in 4.4 for all but the 4 root daemons, but significant
> work has gone into AOSP since 4.4 such that almost everything is fully
> confined+enforcing in AOSP master and is expected to be that way in L.
> The L Developer Preview had most domains confined+enforcing, including
> untrusted_app. See my Android Builders Summit slide deck or (next week)
> my LSS talk.
>
> Also, Samsung has been shipping untrusted_app in enforcing for quite a
> while on their devices, albeit with a more liberal policy than ours.
>
We agree it is better if untrusted_app is enforcing, but I was just
commenting on the current reality. Perhaps a better use case was the policy
I mentioned where SD Card access is not allowed by SELinux policy for a
specific user rather than the whole device.
> If permissive or unconfined, then it can steal the passphrase, or just
> wait for the managed space to mount the decrypted content and then
> access it. ecryptfs does not protect against root.
>
True. It is about layers of security and the specific threat model. If the
device is stolen, then rooted, then ecryptfs is effective, but there are
threat models where it will not help.
> See for example Docker "containers do not contain". They recognize that
> namespaces do not in themselves provide security and are in fact using
> SELinux to provide isolation.
>
I think namespaces has improved since that article was written, but to be
clear we are not advocating namespaces as a replacement for SEAndroid, but
rather namespaces as an enhancement to SEAndroid. We like layered security,
because nothing is bullet proof.
>
>
> Not if they are permissive or unconfined. This is not a safe model.
>
I agree it is not perfect, but it is better than stock Android. Happy to
discuss further sometime.
Cheers,
Chris.
On Thu, Aug 14, 2014 at 10:04 AM, Stephen Smalley <[email protected]> wrote:
> On 08/14/2014 09:37 AM, Chris Stone wrote:
> > 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.
>
> This was true in 4.4 for all but the 4 root daemons, but significant
> work has gone into AOSP since 4.4 such that almost everything is fully
> confined+enforcing in AOSP master and is expected to be that way in L.
> The L Developer Preview had most domains confined+enforcing, including
> untrusted_app. See my Android Builders Summit slide deck or (next week)
> my LSS talk.
>
> Also, Samsung has been shipping untrusted_app in enforcing for quite a
> while on their devices, albeit with a more liberal policy than ours.
>
> > 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.
>
> If permissive or unconfined, then it can steal the passphrase, or just
> wait for the managed space to mount the decrypted content and then
> access it. ecryptfs does not protect against root.
>
> > 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.
>
> See for example Docker "containers do not contain". They recognize that
> namespaces do not in themselves provide security and are in fact using
> SELinux to provide isolation.
>
> > 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.
>
> Not if they are permissive or unconfined. This is not a safe model.
>
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
