On Fri, Aug 23, 2013 at 1:19 PM, Stephen Smalley <[email protected]> wrote:
> On 08/23/2013 03:16 PM, William Roberts wrote: > > Thoughts on versioning: > > > > So a problem exists where an ota, or userdata update can partially update > > the files. Also, an OTA can come in that contains a newer policy then > > userdata. So assuming that userdata is the newest, is not always > feasible. > > Time stamping on release servers, drift, etc, make using a time stamp not > > feasible. > > > > Initially, I thought the client setting policy in data could just wake up > > on boot, check against a list of hashes and versions internally, and > remove > > the stale ones from userdata, reboot, and viola, your on the OTA files > (or > > invoke it via the setprop). > > > > This would require the update agent to know which is older and newer, > > perhaps time stamp on the device, or something, but those could be wrong > > too. Essentially, it needs a cohesive way to know what version it is, so > > the system can apply the proper policy. > > > > Their is essentially two issues here: > > 1. How do we keep files from being partially updated incorrectly > > 2. How do we know which version is the correct one to apply > > > > For issue one, Josh suggested a db and then a zip. He initially just > though > > of data, however the larger takeaway is perhaps a container of some sort > is > > a good way to keep the policies as a cohesive unit (solving number 1) for > > both ramdisk and data.Not sure what the best container format would be, > > offhand. > > > > Issue 2, we just need a way to know that this policy version is higher, > > please use it instead. Updating agents, places policy is reloaded, > whatever > > may want to make use of this. So having it as a part of the core > container > > (bundle) of policy files would be nice as well as an interface for > > extracting them, etc. Then the larger issue is just properly creating the > > version number. > > > > Just my 2 cents, and is not meant to be the direction we have to go, but > > rather get a good discussion on how we can solve these issues together. > > If we go the signed zip route, let's use a whole-file signature (as used > by OTA updates) please. Less prone to the recent APK signature nonsense. > > If I recall, its just running jarsigner on the apk, correct? > Do we need to preserve the existing policy bundle format introduced in > 4.3 or is that something we can eliminate in favor of just a signed zip > file? > We might not have to rework that interface, but rather the backend extraction and wherever the bundle is created. The bundle must just be a single object, the zip file. > > If I understand correctly, you want to avoid having to take the policy > bundle / zip and expanding it out on the filesystem as is presently done > by the SELinuxPolicyInstallReceiver. Instead, you want all code that > loads policy files to directly open the bundle/zip, validate it, and > extract whatever files it needs from within into memory. Is that right? > Yeah something like that. > And if there is one under /data/security, you want to open both, > compare their version numbers (stored within the bundle/zip), and then > decide which one to use? > Yes -- Respectfully, William C Roberts
