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
