On 08/27/2014 12:31 PM, Dinesh Garg wrote: > Hi All, > Following is my understanding w.r.t. policy update: > > Local update (when you've new policy and device to use adb command): > - Compile SELinux kernel policies > - Push policies to /data/security/current > - Push selinux_version to /data/security/selinux_version > - Setprop selinux.reload_policy to 1 > - If /selinux_version matches /data/security/selinux_version, it will > trigger reload of the policy
You can only do this if you have a userdebug/eng build or otherwise have full root (including access to a SELinux domain that is permissive or otherwise allowed the necessary permissions) on the device since you cannot otherwise push to /data/security/current. Should not be possible on a -user build. > OTA Update (When OEMs update policies to many many devices using OTA > mechanism) > - ConfigUpdate mechanism to support SELinux policy updates > - Create a signed policy bundle to be shipped to the device > - Broadcast UPDATE_SEPOLICY Intent to trigger validation & unpacking of the > bundle > - Trigger a policy reload to load the new policy files > I wouldn't call this an OTA update since that normally implies a firmware update. It is just an instance of the ConfigUpdate mechanism in Android, which is used for various kinds of configuration updates. > My understanding is local update is meant for debugging purpose ? Well, yes, and also the same underlying mechanism is used by the ConfigUpdate mechanism, i.e. it unpacks the files under a subdirectory of /data/security, links /data/security/current to that subdirectory, and then sets the same property to trigger the reload. > For OTA updates, I have following questions: > Policies, delivered using OTA, are verified only once when received and > pushed to /data/security/current and thereafter used from /data. /data is > mounted very late in device boot up sequence, how does selinux consumes > these policies from /data. > > Does it load policies first from ramdisk and then later update those from > /data/? Yes. There is a setprop selinux.reload_policy 1 in the init.rc post-fs-data section to trigger the reload from /data/security/current if present. > If someone is able to store/overwrite policies in /data, it would create a > persistent breach of policies. Instead, if we deliver OTA as boot.img which > is verified every time device boots up, it would prevent any such > persistent threat. Not necessarily, unless you take steps to ensure that there is no other way that policy can be loaded after the initial load. It was our impression that requiring a firmware update for every policy update would be an obstacle to adoption, although we have no hard data there. Particularly for early adoption where policies may not yet be sufficiently mature/robust for every contingency. > Are we relying upon assumption that none can change /data/security? Yes. Under AOSP master policy, only the system_server can modify /data/security, which is required so that the ConfigUpdate mechanism can write the policy files there after validation. An alternative would be to have init or the kernel verify a signature on the policy before loading it, in which case merely being able to write to /data/security is no longer sufficient to get a policy loaded. That would be possible (with code changes to init or the kernel). > If yes, what are other assumptions we have for SELinux to work securely? Kernel and policy correctness, of course. _______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
