Thanks for your comments, Stephen.
A few more comments inline below...
On Apr 29, 2015, at 10:53 AM, Stephen Smalley <s...@tycho.nsa.gov> wrote:
> On 04/29/2015 10:10 AM, Clifford Liem wrote:
>> Background:
>>
>> We are using eCryptfs as a way to encrypt directories as well as PID
>> namespaces as a way to isolate processes.
>
> I believe Samsung has been using ecryptfs as well, not sure how they are
> addressing it, but perhaps they can do all of the mounting from vold or
> zygote.
Yes, we heard from Samsung (from my ex-Cloakware colleague!) that they did it
from vold, which we have
also done in an earlier implementation.
>
> Wondering how use of PID namespaces might affect binder services that
> rely on the sender PID information provided by the kernel binder driver
> and those that rely on getpidcon(), e.g. servicemanager and keystore.
>
> We've created
>> native processes that run in different namespaces and need to mount/unmount
>> directories.
>
> You can't do this from vold or zygote?
We can and we have, but we feel our current implementation is better because we
have isolated the limited functionality needed within executables that have
specific jobs. We could easily add all the functionality to vold or zygote and
use these executables in different contexts, but then we feel we are giving the
executables too much access in a new context.
>> We've allowed eCryptfs to use xattributes with fs_use_xattr:
>> e.g.
>> fs_use_xattr ecryptfs u:object_r:labeledfs:s0;
>>
>> And we've added allows for native daemons to mount/unmount directories:
>> e.g.
>> allow namespaceinit labeledfs:filesystem remount;
>> allow namespaceservice labeledfs:filesystem mount;
>> allow namespaceservice labeledfs:filesystem unmount;
>
> Wondering how many domains are in these attributes, and how well
> protected they are from apps and shell.
>
The domains are similar but more constrained than the vold and zygote domains.
>> This led us to need to add exceptions in certain neverallow statements:
>> e.g. external/sepolicy/domain.te (added -namespaceinit -namespaceservice
>> -labeledfs)
>> neverallow { domain -kernel -init -recovery -vold -zygote -namespaceinit
>> -namespaceservice } { fs_type -sdcard_type -labeledfs }:filesystem { mount
>> remount relabelfrom relabelto };
>
> Not sure why you added -labeledfs; that defeats the entire purpose. I
> understand exempting the specific domains. But you want the labeledfs
> restriction to still be applied for all other domains.
>
I agree that adding -labeledfs is allowing many of these domains too much reign
(but only if allows are added), but we needed to allow our namespaces processes
to mount ecryptfs directories. We could use a different type here for ecryptfs,
but we will still need to modify the neverallow, unless we overload the
sdcard_type, which just seems wrong. The CDD restriction ties our hands. Should
the fs_type here be a more general type than sdcard_type (but not as general as
labeledfs)? The problem is that modifying the fs_type set cannot be achieved
with the 'must not modify' restriction.
It seems to me that ‘must not modify’ should be language more like ‘must not be
made less restrictive’.
>> However, CDD is extremely restrictive on making any changes to neverallows:
>>
>> ● MUST NOT modify, omit, or replace the neverallowrules present within the
>> sepolicyfile provided in the upstream Android Open Source Project (AOSP) and
>> the policy MUST compile with all neverallowpresent, for both AOSP SELinux
>> domains as well as device/vendorspecific domains
>>
>> We could argue that we are not weakening security, but making security
>> improvements to the system with new encryption and isolation mechanisms.
>>
>> We understand the spirit of these clauses in the CDD is to not allow the
>> security to degrade; however, these recent CDD statements are hand-cuffing
>> us from adding new security features.
>>
>> Questions:
>>
>> 1. Is there any SELinux way to get around us changing the neverallows? (e.g.
>> creative labeling? sub-typing? are we stuck with the current labeling?)
>
> Could the mounts be set up by the zygote, similar to how it already sets
> up various mounts?
Yes, but as I stated above, not desirable.
>
> Technically you could use a new type not in fs_type for your
> fs_use_xattr statement but that would be a hack.
>
What do you mean by hack? Is a new type not recommended? Surely alternative
filesystems are allowed. Does the system allow for this?
Again, we are still left with the neverallow problem.
>> 2. Is there any negotiation process for statements in the CDD? What steps
>> can we take?
>
> That's likely a question for the android-compatibility list rather than
> here.
Thanks - this is the list I found, but it only has 4 old posts:
https://groups.google.com/forum/#!forum/android-compatibility-cdd-cts
Maybe there’s another one you know of? One a little more active?
>> 3. Other ideas?
>
> None besides what I suggested above.
Thanks for all your comments.
Much appreciated,
Cliff
_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to
seandroid-list-requ...@tycho.nsa.gov.
