> 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. I did not understand this. Can you please elaborate a little more ?
>> 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 you suggesting that delivering policies through firmware upgrade is a safer mechanism compared to configupdate ? >>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. Do you envision any way there could be privilege escalation despite SEAndroid ? >> 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). This sounds good. Do you plan to upload code changes? On Wed, Aug 27, 2014 at 10:15 AM, Stephen Smalley <s...@tycho.nsa.gov> wrote: > 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.
