Re: Joining this list - with some comments

[Andreas Wolf]

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?    Cheers,      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.