> Oh is that all its getting? I thought the data was read across that binder transaction.
Where are you seeing that? > 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. 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 > >
