On Thu, Aug 29, 2013 at 12:20 PM, Andreas Wolf <[email protected]> wrote:
> 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. > >From what I gather here, you're saying that early in init, you can change the sebooleans to some other value then what was set at build time? If that is the case, why don't you just use BOARD_SEPOLICY_REPLACE and some other build time config magic to change the value? You could also do a setbool in the init script, and use init's import + properties to set up some type of run time initialization. Not sure of what the value is versus @ policy build (new policy + reload) > > 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. > A lot of what you have would need a map. A single SE Boolean may map to many features, and vice versa. > > 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 > [email protected] with the words "unsubscribe seandroid-list" > without quotes as the message. -- Respectfully, William C Roberts
