On 04/29/2015 10:08 PM, Clifford Liem wrote: > 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.
I wasn't suggesting using the executables in different contexts. It just seemed that zygote is already well positioned since it performs the initial setup of each app process when it forks and already creates private mounts for the app process. Not sure why this isn't a straightforward extension to it. > 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. But you don't need to add -labeledfs. You only need to exempt either the domains in question or the type in question, not both. And in this case, you only want to exempt specific domains, while still restricting all other domains to not being able to mount/remount/unmount labeledfs. > 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. labeledfs is the most important one to protect, since it applies to the /system partition. > It seems to me that ‘must not modify’ should be language more like ‘must > not be made less restrictive’. Ironically that is exactly what you just did. You opened up the potential for arbitrary domains to mount/unmount/remount /system and other partitions. >> 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. Adding a new type is fine; the issue is that the neverallow prohibits mount et al for any type in fs_type except for those in sdcard_type. Typically if you add a new filesystem type for ecryptfs or whatever, you would still assign it the fs_type attribute so that allow rules written on fs_type would apply to it as well. But this presents a problem for the neverallow. You could not assign your new type the fs_type attribute to avoid the neverallow, but then you must manually identify all existing allow rules on fs_type and replicate them if you want them to be preserved. That's why I didn't recommend it. >>> 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? The official contact info for compatibility questions is: http://source.android.com/compatibility/contact-us.html _______________________________________________ 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.
