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.
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'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.
> 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.
> 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?
Technically you could use a new type not in fs_type for your
fs_use_xattr statement but that would be a hack.
> 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.
> 3. Other ideas?
None besides what I suggested above.
_______________________________________________
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.
