On Wed, Aug 27, 2014 at 9:31 AM, Dinesh Garg <dinesh.g...@gmail.com> 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 > > 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 > > My understanding is local update is meant for debugging purpose ? > > 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/?
It starts with the policies on ramdisk and switches during the boot process by an explicit setprop selinux.reload_policy 1 in the init.rc AFTER the data partition is mounted. > 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. boot.img verifications are vendor specific. Not All Android devices verify boot.img and those that do often fail at doing it right. Also, its only boot verification not run time checking so things like Towel Root are still valid, they just don't persist. > > Are we relying upon assumption that none can change /data/security? If yes, > what are other assumptions we have for SELinux to work securely? That is one assumption. You also assume that the kernel integrity at run time is not comprimised like in Towel Root. > > Thanks, > Dinesh > > _______________________________________________ > 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. -- Respectfully, William C Roberts _______________________________________________ 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.
