On 08/29/2013 02:48 PM, Andreas Wolf wrote: > Hi, > > On 8/29/2013 2:10 PM, Stephen Smalley wrote: >> On 08/29/2013 12:20 PM, Andreas Wolf wrote: >>> 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? > Apologies to both Stephen and William. I was a bit "terse" in this > part of the discussion since me email was getting a bit long :-) > > We did actually use the SEAndroidManager for a while, but replaced it > with the feature in "init," I tried to describe above. I believe the > issue addressed is also present when using the SEAdmin, since the "boot" > step that Stephen references is the "BOOT_COMPLETED" sent through the > Android framework, which is still too late. > > To clarify, the issue is the use of an SE Boolean, that has a default > value to disallow the use of a device (via a service started by "init"). > Through an MDM/SEAdmin tool I now re-provision a device to change the > value to "allow". I do not want to send up a new SE policy file with new > defaults, but instead just want to change the value of that one Boolean > (otherwise, I would have not used a Boolean in the first place) and thus > make the device functional. If I now reboot the device, I will have the > default value of that SE Boolean "active" when the kernel starts until > the mechanism "kicks in" that changes it to the new value. Any mechanism > based on an Android app, started after the framework has become active, > will be too late in this case. > > Does this help? Or am I still missing something?
SEAdmin is fundamentally different than the old SEAndroidManager; it sets the values via the system_server's device admin APIs, and it is the system_server that handles saving and restoring them on boot based on device_policies.xml. So it happens before any apps are launched. -- 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.
