Joining this list - with some comments

[Andreas Wolf]

Hello everyone,   I'm writing to this list to give some feedback on a project we worked on, using SEAndroid as a means to controll access to resources on an Android tablet that can be adjusted through an MDM (or equivalent tool) during run-time or provisioning step, after the ROM is fully built and deployed.   We started to work on this some time ago with the ICS 4.0.4 base line, since we needed a stable source tree to evaluate the feasibility of the design and needed time to implement all requirements without needing to roll in updates too often. We also back-ported the Intent-Filtering feature from the JB version of SE Android to the ICS code base, which we think is a "one off" and not of interest for the rest of the user group.   We are now in the process of updating to JB 4.3, and we see similar changes in this latest code that we had added to our "forked" 4.0.4 version:     a) The list of Boolean names were separated into its own file and parsed before all other "TE" files;        We had discovered this to be crucial for some SE Booleans that are used in multiple TE files.     b) The handling of the public key values was changed to be based on files, referenced by some name;        We had written our own script to replace the "reference name" with the actual value of the public key.     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);   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.     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.    If you need to contact us directly, please reply to both my email and the other one, since I may be traveling, soon.    Thanks, and have a great day.        Andreas =:-) -- Remember, Experience Gained is Directly Proportional to the Amount of Equipment Destroyed! -- This message was distributed to subscribers of the seandroid-list mailing list. If you no longer wish to subscribe, send mail to majord...@tycho.nsa.gov with the words "unsubscribe seandroid-list" without quotes as the message.