> No I don't think its finalized either by looking at it. So its just passing paths?
That path should be in the EXTRA_CONTENT_PATH intent extra passed to ConfigUpdateInstallReceiver. > so it could just pass the path to the policy zip. Hmmm. I would think so. But the ConfigUpdateInstallReceiver code right now expects a certain format and that is where the new verification code would have to go. On Fri, Aug 23, 2013 at 5:15 PM, William Roberts <[email protected]>wrote: > > > > On Fri, Aug 23, 2013 at 2:09 PM, Robert Craig <[email protected]>wrote: > >> > Oh is that all its getting? I thought the data was read across that >> binder transaction. >> >> Where are you seeing that? >> > > Again, didn't read through it fully, so my ignorance is to blame here. > >> >> > If its not, then why even send any of that information across the >> interface. It could just be, "HEY, there's a new policy". (more of an >> intent at this point). Then the receiver can go get the signed zip, verify >> the signature, and take appropriate reload action. The bundle/intent would >> just need a path or fd to the update. I prefer fd's, just me though. >> >> I guess there are many roads to Nirvana here. So far they have decided to >> implement it this way but I don't believe the code is finalized yet. It >> exists in 4.3 but doesn't appear to be active. But what you just described >> is essentially what is happening with the current code. It's just not using >> a passed fd. >> > > No I don't think its finalized either by looking at it. So its just > passing paths? so it could just pass the path to the policy zip. > > >> >> >> >> >> On Fri, Aug 23, 2013 at 5:03 PM, William Roberts < >> [email protected]> wrote: >> >>> >>> >>> >>> On Fri, Aug 23, 2013 at 1:53 PM, Robert Craig <[email protected]>wrote: >>> >>>> > IMO, I would drop the bundle, and make the interface take the zip and >>>> reconstruct it. >>>> >>>> Having the ConfigUpdateInstallReceiver.java take a zip isn't a big >>>> overhaul. Can easily be done. Again, the extraction and verification code >>>> isn't too bad as I've labored through that already. >>>> >>> >>> I am not concerned about changing code, extracting, verifying, etc. My >>> concern is, someone is reading the policy update zip data and transferring >>> it across a binder interface. Now we have to sides keeping data resident in >>> memory. Do they both read the entire zip into memory before sending it? >>> Even if they send it in fixed chunks and reuse memory buffers, wouldn't be >>> more simple (and use less memory) to just send an fd? -- You may be >>> addressing this concern below, I really didn't review the code in detail. >>> >>>> >>>> >>>> > My only concern is how do we deal with super big zips. Does Bundle do >>>> anything smart and send it piecemeal and store it on disk? >>>> >>>> I'm a bit confused and might be missing something from the >>>> conversation. But, once the zip exists in /cache, which is delivered by >>>> some other service on the phone, then what exactly is being shipped across >>>> binder that is so large. The current ConfigUpdateInstallReceiver simple >>>> receives the signature, version, hash in the intent and verifies it all. >>>> Once successful, then the zip (bundle) from /cache is opened and the files >>>> are copied in to their correct places as needed. >>>> >>>> Oh is that all its getting? I thought the data was read across that >>> binder transaction. If its not, then why even send any of that information >>> across the interface. It could just be, "HEY, there's a new policy". (more >>> of an intent at this point). Then the receiver can go get the signed zip, >>> verify the signature, and take appropriate reload action. The bundle/intent >>> would just need a path or fd to the update. I prefer fd's, just me though. >>> >>>> >>>> On Fri, Aug 23, 2013 at 4:45 PM, William Roberts < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Fri, Aug 23, 2013 at 1:40 PM, Robert Craig >>>>> <[email protected]>wrote: >>>>> >>>>>> > If I recall, its just running jarsigner on the apk, correct? >>>>>> >>>>>> The OTA update zip uses the signapk jar with the -w option (whole >>>>>> file option). Apks are signed with signapk but without that option. The >>>>>> current update bundle format used by 4.3 ( >>>>>> ConfigUpdateInstallReceiver.java) should still be usable as it hashes >>>>>> (sha512) and then signs the entire bundle. I would think we can leverage >>>>>> that existing mechanism for this if needed. Upon delivery of the bundle >>>>>> along with the metadata, the code can just open the otacerts.zip file on >>>>>> the phone looking for a matching public cert. >>>>>> >>>>> >>>>> Ahh yes signapk... I was doing work with the OTA's unpacking them and >>>>> resigning them by hand, that should have been at the top of my mind. >>>>> >>>>>> >>>>>> Although, if your looking to push just a zip file containing all this >>>>>> stuff then we can just use signapk with the -w option which appends the >>>>>> signature to the zip in the comment field. Extraction code isn't too bad, >>>>>> I've written it before. >>>>>> >>>>> >>>>> IMO, I would drop the bundle, and make the interface take the zip and >>>>> reconstruct it. My only concern is how do we deal with super big zips. >>>>> Does >>>>> Bundle do anything smart and send it piecemeal and store it on disk? >>>>> >>>>> >>>>>> >>>>>> >>>>>> On Fri, Aug 23, 2013 at 4:24 PM, William Roberts < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Respectfully, >>>>> >>>>> William C Roberts >>>>> >>>>> >>>> >>> >>> >>> -- >>> Respectfully, >>> >>> William C Roberts >>> >>> >> > > > -- > Respectfully, > > William C Roberts > >
