On 8/29/2013 2:50 PM, Stephen Smalley
wrote:
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.
I see! I will investigate this feature in the "system_server" code
some more. It could be just early enough to cover the case we were
discussing.
Thank you very much,
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.
|
