On 08/29/2013 12:20 PM, Andreas Wolf wrote: > c) There is the intention to further support the "Intent MMAC" > feature to selectively allow specific apps usage of certain intents to > access resource (e.g. Camera);
We are considering re-implementing the Intent MAC functionality using the new support in 4.3 for "IntentFirewall" (see frameworks/base/services/java/com/android/server/firewall). > While working on the SEAndroid side of the project we think we found > some improvements that may be of interest to the wider audience. Maybe > these can be discussed by this group? > > a) Handle the change of a "bool" from default to a different value > in "init", before any services can start; > Use a simple name/value pair file in /data/security, > appropriately labeled, to save and read; > > The use case for this feature is this: A lower-level service > process "G" is started by the "init.rc" scripts, which allows the > Android framework to connect to and control a hardware device. This > connection/pipe is started early within the Android framework when that > device is discovered as supported. The SE Boolean to controll the access > to the hardware was designed to disallow the connection from the > framework to this service (chosen this way b/c of some constaints). The > current framework, however, is not prepared for a failure when making > the connection, and therefore gives up using the device if SEAndroid > refuses to allow the connection. Since the process that controls the > state of a SE Boolean *starts later* (as an application), "allowing" the > connection at that point is already too late for the framework to > correctly use the device. > > The proposed change would avoid this case, since the SE Boolean > values are set to their needed values much earlier. There are presently several ways to set booleans from the defaults: - You can replace the bools file during build via BOARD_SEPOLICY_REPLACE in your BoardConfig.mk file, - You can set bools via setsebool built-in commands in the init.rc file, - You can use SEAdmin and the underlying device admin APIs, which save the booleans as part of /data/system/device_policies.xml configuration and restores it on boot _before_ any apps start. I'm guessing you are describing the old SEManager app that predates the device admin APIs or some other custom app of your own? Anyway, can't you use one of the above mechanisms to achieve your goal? > b) Use SE Boolean values to enable "Intent MMAC" entries, thus > allowing for instance Camera access to only a certain set of apps after > it is allowed, "in principle"; > > We think it would simplify the process of enabling a "resource" > and the related allowed intent "sources" by only changing one "thing" in > the system. This change would only involve the XML schema update and > some added test logic in the "Intent MMAC" support code. > > c) "Combine" the handling of the availability of a feature [e.g. > PackageManager.hasSystemFeature(PackageManager.FEATURE_CAMERA)] and a > "pre-defined", named SE Boolean, so that: > hasSytemFeature() returns "true", iff "device supports > camera" AND "SE Boolean allows its use"; > Reflect this also in the method "getSystemAvailableFeatures()"; > > We tried to avoid crashes of apps, and the display of invalid > "Settings" options, by adding code that reads the actual SE Boolean > value in "various places." These changes could be simplified by folding > the SE Boolean into the "feature" list as a "gate" in some way. > > d) Propose an addition to the AOSP PackageManager that reads > "hasSystemFeatureAllowed()" to only read the state of the SE Boolean > related to this feature, and create a "name space" for strings > describing features only controlled by those values, that are not part > of the standard feature list (to be defined by SI groups creating the > ROM). For example a "SEBool_" prefix with an appended string for general > use. > > Not sure, if this would be acceptable to Google, though... but we > needed control of things on a finer-grained level than a "System > Feature", and we currently have many code lines reading SE Boolean > values "sprinkled" over the source tree. Haven't given much thought to these yet, but again note that we are considering switching over to the IntentFirewall code in 4.3 and extending it to support the larger range of functionality previously addressed through Intent MAC. -- This message was distributed to subscribers of the seandroid-list mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe seandroid-list" without quotes as the message.
