Background:

We are using eCryptfs as a way to encrypt directories as well as PID namespaces 
as a way to isolate processes. We've created
native processes that run in different namespaces and need to mount/unmount 
directories.

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;

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 };

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?)

2. Is there any negotiation process for statements in the CDD? What steps can 
we take?

3. Other ideas?


Thanks,

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.

Reply via email to