Sandbox build
Rimas Mickevičius
some time ago (I guess before moving to the github) I saw a branch with sandboxing. Is it somewhere still available? Trying to sandbox app with iMedia 2 browser.
Regards,
Rimas M.
Peter Baumgartner
Check out my branch "experimental-SandboxedVersion" at
https://github.com/peterb180369/iMedia
I handled a couple of issues that we need to tackle in a sandboxed world. However, the most important part - moving parts of the code into xpc processes - is still missing. Dan mentioned that he wanted to look into this, but I don't know how far he already got. Dan, any updates on this topic?
Peter
Dan Wood
Has anybody here on this list done any XPC stuff at all yet? I might be able to dig into it in a while -- we're going to have to bite the bullet and get Sandvox in the Sandbox soon - but it would be great if somebody has already gotten a bit familiar with it, and could help figure this part out.
- Dan
Jörg Jacobsen
Dan Wood
- I know that Peter Baumgartner had mentioned that he had started an experimental sandboxing branch on Git. I haven't had a chance to look at that yet.
- We should be able to have the same code base work in 10.6 (and 10.5?) as well as 10.7. The suggestion I got from Ivan ("Aerie" on the Apple dev forums), the lead Sandboxing engineer, was to write the code in such a way that you could link it in and call it directly from 10.6, but then use XPC to call it when under 10.7. I don't have any more specific details than that, but I think it can be done.
- I can try to help a bit. I want to get it done, but I'm bogged down getting ready for a new release of Sandvox (with a "v"), Macworld Expo next week, and then a vacation.
- We can probably set up a sandbox branch in anybody's repo that people can contribute to, or issue pull requests to.
- Haven't seen XPCKit. Sounds interesting!
- I would love to see such a statement too, but I don't imagine it's forthcoming. Most of my thoughts come from talking with Aerie last August. I will try to summarize his suggestions:
* There are some aspects that just aren't supported, like being able to permanently bookmark a file or directory and have access to that file for later. That's something that, back in August, he said he was working on with a big priority. I haven't heard of any new OS versions that have improved things, though.
* Aerie's main suggestion was that we re-architect iMedia in such a way that it is compartmentalized into code that does the discovery or the fetching of the image data. You'd have an XPC process it will have a lot of trust for the file system, but basically no trust for anything else. In other words, it would get very wide file system entitlements. You would communicate with it through some kind of tokens (numbers, UUIDs, hashes, etc.) from your main process, so that your main process doesn't know anything about the specific file paths. (I think it would be much better *not* to have networking entitlements from a pricess with such wide reading access.)
* Also he suggested another way to prevent attacks - to verify the type of data, though only lazily as needed. Basically doing something like an ImageIO call (or some other kind of file check like a /usr/share/file/magic check) just to make sure that the data is of the appropriate type, e.g. to prevent somebody from hacking in a way that causes iMedia to give somebody's data file of some other type.
* Usually we need read-only access, though HoudahGeo needs to write to files as well, so we should think about that.
- Ted Slupesky of Plasq had mentioned some interest in this issue. Hopefully he's here and can help.
Hopefully that is a good start. It's probably time we dig in.
Peter Baumgartner
On 18.01.2012, at 16:44, Jörg Jacobsen wrote:
> Hi everyone,
>
> I am in for helping sandboxing the iMedia browser. My knowledge about the topic is yet quite limited (started reading the docs and the example code) but I am quite curious about it. I am aware of everything that was mentioned about the topic on this mailing list and what Peter prototyped in his sandbox branch. Are there any other efforts already underway?
>
> I would also like to raise a couple of questions/statements to push our effort:
>
> - The sandboxed version of iMedia will be 10.7 and up only?
Since XPC is Lion only, I guess we can safely build upon Lion technolgies, i.e. also on GCD and blocks. Would this then be considered iMedia 2.5 or rather 3.0?
> - Who intends to be contributing to the effort (and possibly focussing on what)?
I'd was planning to contribute on the general design concerning parsers, and IMBLibraryController, and adapting them to the new strategy, since I was the one who wrote the 2.0 implementation.
> - We should have a look at XPCKit by Steve Streza (on github) which is an object wrapper for the XPC API
Yes, it seems that it relieves us from writing a lot of boiler plate code - i.e. if XPCKit is already stable enough.
> - I would find it helpful if we could get a statement from Apple as accurately as possible what they would approve and what not (e.g. network and root directory read access from within the same XPC bundle is ok?)
Dan, what exactly did Aerie say at the Lion dev kitchen?
Peter
Dan Wood
- The fact that imedia is open-source is a plus, in their determining whether to grant such high privileges as reading the whole file system
- We want to compartmentalize the pieces that have high trust into the minimum functionality
- The trusted process should not be vending any real information (like paths) to the client app (or framework). So use just numbers or IDs to represent each file.
- If a process has very high trust in one area, it should have low/no trust in the other areas. So for instance you wouldn't want to grant network access to a process that has full read/write access to the file system.
- Surprisingly, they are worried more about renegade writing, not renegade reading. So if we are granting write access to the XPC processes, we should do it carefully. (Maybe Pierre can weigh in here - what is it you are doing with writing? You are changing metadata of images, right? Maybe we can package up a metadata-writing request from the client application, and then iMedia can hand that metadata over the "wall" and let the XPC process do the actual file manipulation.
Basically, it comes down to an evaluation by their team about how to handle requests for exemptions. So if they see what we are doing, and what kind of data we are passing into and out of privileged processes, we should be OK>
Peter Baumgartner
On 18.01.2012, at 17:45, Dan Wood wrote:
> Well, I can't quote a conversation from several months ago, but let me see if I can remember the salient points:
>
> - The fact that imedia is open-source is a plus, in their determining whether to grant such high privileges as reading the whole file system
Good to know.
> - We want to compartmentalize the pieces that have high trust into the minimum functionality
Sounds reasonable.
> - The trusted process should not be vending any real information (like paths) to the client app (or framework). So use just numbers or IDs to represent each file.
Ouch! I see a real problem here for many host apps. How is the iMedia framework supposed to anticipate how the different host want to access media data and what to do with it. I was really hoping that we could pass some kind of file system identfication across. Was thinking of NSURL with this new style that kinda works like an alias?
> - If a process has very high trust in one area, it should have low/no trust in the other areas. So for instance you wouldn't want to grant network access to a process that has full read/write access to the file system.
Sounds reasonable.
> - Surprisingly, they are worried more about renegade writing, not renegade reading.
Didn't you tell it the other way round last time we talked about this issue?
Peter
Dan Wood
On Jan 18, 2012, at 8:56 AM, Peter Baumgartner wrote:
>
>> - The trusted process should not be vending any real information (like paths) to the client app (or framework). So use just numbers or IDs to represent each file.
>
> Ouch! I see a real problem here for many host apps. How is the iMedia framework supposed to anticipate how the different host want to access media data and what to do with it. I was really hoping that we could pass some kind of file system identfication across. Was thinking of NSURL with this new style that kinda works like an alias?
I think that breaks the whole point of sandboxing, unfortunately. We'll have to be passed some token. It could just be an NSInteger, but it might be better to be something like a hash of the path so it's easy to confirm matching (in one direction at least). We'd have some lookup dictionary maintained by the XPC process to look up each URL based on the token.
I think that we need to break it into two phases - one is the discovery phase, where we scan for photos and such. The XPC process would then vend a token to the client iMedia framework for each item it finds. Then, when iMedia wants to display a thumbnail, or get the actual data itself, it would pass a request with that token to the XPC process and ask for the actual image or data.
>> - If a process has very high trust in one area, it should have low/no trust in the other areas. So for instance you wouldn't want to grant network access to a process that has full read/write access to the file system.
>
> Sounds reasonable.
>
>> - Surprisingly, they are worried more about renegade writing, not renegade reading.
>
> Didn't you tell it the other way round last time we talked about this issue?
>
Yikes - now I"m confused -- maybe I had gotten so used to something counterintuitive, that I flipped around in what was counterintuitive. I don't recall now!!!!
Peter Baumgartner
- get thumbnail image (CGImageRef)
- get name (NSString)
- get metadata (NSDictionary)
- get media data (NSData)
- get hires image (CGImageRef, NSImage, or CIImage)
- what about movies, audio etc?
I guess we should also have a bulk accessing mechanism so we can get multiple things at once, instead of having to do multiple round trips, e.g. when displaying the image browser with thumbnail, name and metadata. Did I miss anything important.
On 18.01.2012, at 17:45, Dan Wood wrote:
Dan Wood
Actually, I think that it would be the best idea to pass as little information as possible over the "bridge" to and from the XPC process, so it's very clear that very little damage could occur. So I think we are better off with just a string token. If we pass an object, I could imagine (though I'm not certain) that somebody might think this is too risky.
Peter Baumgartner
MBObject.identifier would be technically possible, I guess. It is supposed to be unique across the system - and for various reasons it is also persistent across launches. So this string could probably be used as a key in a lookup dictionary inside the XPC bundle. So the API on the client side would say something like:
- (NSData*) dataForObject:(IMBObject*)inObject;
but what is actually passed across to the media access XPC bundle is just the identifier. Another question: Are synchronous return values supported in XPC? Or would we have to leave out the return value in the API and pass in a completion handler block instead:
- (void) getDataForObject: (IMBObject*)inObject completionBlock:(void(^)(NSData* inData))inCompletionBlock;
Things like thumbnail, name and metadata of course would have to be assigned to the IMBObjects properties again (on the client side), so that efficient (cached) drawing is possible in the browser views…
Peter Baumgartner
1) It needs to be persistent across launches, so that host apps can store it in documents or in their prefs files
2) For those host apps that choose not to be sandboxed (not on the app store) direct files access would be nice to have. BTW, are any iMedia users choosing not to be on the app store?
3) It should be a robust mechanism
Considering those 3 points I came to the conclusion that passing an opaque token string might not be such a good idea after all. How about just passing a NSURL (file reference url in the case of local files). Sure, the host app would know about the location of a file, but I don't think this would be a security risk, as the host app cannot read or write the file (if it is sandboxed). However, it can store the url in its document data model in a persistent way. Apps that are not sandboxed can access the file directly. Apps that are sandboxed would pass the url to the new "media access XPC bundle" to do the job for them.
Using a NSURL as the token would also eliminate the potentially problematic lookup map between tokens and real file paths in the XPC bundle. Imagine what would happen if this lookup table became corrupted, or if entries are missing. All moot points if we just use a NSURL that carries the location information directly. I also have an additional hope about using NSURL. I recall hearing somewhere that Apple was considering using NSURL to store the information, whether the user has authorized the app to access a specific file via the NSOpen/SavePanel. No idea whether they went ahead with those plans, though.
Florian Albrecht
just wondering: why are you keeping the basic premise that there will be two implementations of iMedia, one for sandboxing and one 'normal'?
Sure, some apps wanting to use iMedia might not immediately need sandboxing as their developers choose to not offer their products on the Mac App Store for now.
But do you really believe that the world of Mac software development will from now on be split in two and that developers including you fabulous people creating and maintaining iMedia for the community will be able to sustain the development of two separate code bases while at the same time the cost for software continues to decrease?
Some aspects of sandboxing do limit the abilities of software, but by allowing more entitlements the limits can pretty much be removed, can't they? I also totally see that the cost for implementing sandboxing is not exactly what we were looking for in the first place. But it seems this is not really a matter of choice right now. So why not appreciate the increased (potential) stability and rights separation of sandboxing by adopting the model for iMedia in general, regardless of the app using it is actually sandboxed?
The technical reason I see is that XPC is Lion only. Is that really the case? At least as private API it was there before I assume. Wouldn't it then be better to think of an alternative implementation for that isolated part for Snow Leopard (and whatever you want to support) and keep all the rest identical? Yeah, this isn't trivial either, I know. I would also seriously question the need for a pre Lion implementation… By the time this will be ready for shipping 10.8 will likely be almost available. Plus, those in need of support for older OS versions could also stick to the current branch of iMedia and keep maintaining it.
Just a few thoughts…
Cheers,
f l o r i a n
--
Florian Albrecht
Boinx Software.
Houdah - Pierre Bernard
HoudahGeo is the anti-thesis of the sandbox.
- HoudahGeo needs to know the paths of the image files in order to access metadata
- It also needs to access XMP sidecars sitting next to files added to the project
- It needs to write to both the images and their sidecars
- It needs to find masters/originals from the preview images provided by iMedia
- Works with USB / Bluetooth to access GPS devices
- Uses AppleScript to communicate with iPhoto & Aperture
- Runs a HTTP server
- …
I will not even try to make a sandboxed version of HoudahGeo.
Pierre
Peter Baumgartner
On 19.01.2012, at 14:16, Houdah - Pierre Bernard wrote:
> HoudahGeo is the anti-thesis of the sandbox.
> - …
> I will not even try to make a sandboxed version of HoudahGeo.
>
> Pierre
On 19.01.2012, at 09:03, Florian Albrecht wrote:
> But do you really believe that the world of Mac software development will from now on be split in two and that developers including you fabulous people creating and maintaining iMedia for the community will be able to sustain the development of two separate code bases while at the same time the cost for software continues to decrease?
>
> Some aspects of sandboxing do limit the abilities of software, but by allowing more entitlements the limits can pretty much be removed, can't they? I also totally see that the cost for implementing sandboxing is not exactly what we were looking for in the first place. But it seems this is not really a matter of choice right now. So why not appreciate the increased (potential) stability and rights separation of sandboxing by adopting the model for iMedia in general, regardless of the app using it is actually sandboxed?
Okay, so it seems that we should also consider non-sandboxed use of the iMedia framework. And obviously I envision only a single iMedia framework going forward. Florians suggestion sounds good to me, in that we should modify the existing architecture (or add to it) so that sandboxed use is possible, but that non-sandboxed use is also possible without restrictions.
I'd be fine with this new version of iMedia being 10.7+ only. Opinions on that matter, anyone?
Dan Wood
Yes, I see your points, though, for persistent storage. For that, I think what we need to do is assume that there will be some permission where an app can get permissions to access a particular path, and persist those permissions across launches. So maybe we should have a method in the XPC process where we ask for a persistent URL to the resource. Using whatever solution we end up with, the XPC process would somehow grant permission to the app and build up this URL that we are hopping will be persistent across launches.
But for the basic operation of discovery and data transfer, where the source URL of the image or other file is not needed, I think we want to work in terms of opaque tokens, following Aerie's advice.
Dan Wood
So I think that we really need to figure out a way to have the same code base executed from two paths -- one via XPC and one directly. I think it can be done. And then make it 10.6 and 10.7 compatible.
Jörg Jacobsen
Since any XPC service might be exited by the operating system while not handling requests we will have to save to and reload from disk our service's state (e.g. if we created mapping tables). I don't know how often that will happen but I guess it heavily depends on available memory. Apple would like to have us implement (almost) stateless services (Ivan in WWDC 2011 session 206).
As far as I understand media object information in iMedia is usually loaded in two phases:
1. Load some of the object's meta information and a thumbnail representation when presenting the object to the user (populateNode)
2. Load the object's "full" representation when it's thumbnail representation does not satisfy a host application's specific use case of the object
Thus, I envision the following messages to be sent to a "Media Access Service":
1. NodePopulation:
Argument: identifier of a node
Return value: information about all subnodes of this node and about all media objects of this node (excluding the "full" representation of each media object)
2. FullRepresentation:
Argument: identifier of a media object
Return value: the full representation of the media object (but I don't yet understand how to handle movies and audio)
My candidates for "identifier" would be for a node -[IMBNode identifier] and for a media object something unique that we can acquire from its source library (for iPhoto objects this would probably be the object's "GUID"). -[IMBObject identifier] currently includes the path to its resource. If a host app would always copy a resource it was using then identifiers just needed to live until we got a notification that our source library had changed or the user had quit the app. But I guess this assumption is not realistic.
"NodePopulation" would probably qualify for being bulk data transfer.
BTW: From what I saw so far XPC services are always asynchronous and block handler backed to retrieve return values.
Regards, Jörg.
Mike Abdullah
On 18 Jan 2012, at 16:13, Dan Wood wrote:
> * Usually we need read-only access, though HoudahGeo needs to write to files as well, so we should think about that.
I don't see writing to files as any concern of iMedia's. That's up to the host app to implement using its own service.
Daniel Jalkut
Mike Abdullah
I filled out the wiki to cover my thoughts on entitlements so far:
https://github.com/iMediaSandboxing/iMedia/wiki/Sandbox-Architecture
Have I missed anything there?
What else do we have at the moment that stops us from running in a sandbox with reasonable entitlements?
Peter Baumgartner
Right after WWDC I did some sandboxing work. Dan showed the stuff I had done to Ivan at the Lion Dev Kitchen in Cupertino. He said that we would get the necessary (broad) entitlements for iMedia, but only if we factor them out into XPC bundles. So it is absolutely necessary that we do this work now, or iMedia won't have much of a future - i.e. unless Apple chooses to ditch it's plans for sandboxing at the last minute. But I guess that would be wishful thinking ;-)
BTW, the entitlements for reading Music, Pictures, and Movies folders are not enough. We need to be able to read the *entire* file system. Folder parser for one requires that, and iTunes, iPhoto, Lightroom, or Aperture all have the ability to spread their media files all over the place, not just on a single volume, but on multiple volumes. Ivan understood these requirements and told us we would get the necessary temporary exception entitlement (but only if factored out to an XPC service).
Peter
Daniel Jalkut
I am unfortunately doubtful that Ivan has much say in how the sandboxing rules will ultimately be applied. So while we should be encouraged that he suggested there would be a likely approval for this behavior, I don't think we can count on it.
When you say he stressed the need to use XPC for the services, what was the implication for the sandboxed app running under 10.6? That sandboxed apps would have to drop support for 10.6 to gain approval under the sandboxing rules?
Daniel
Daniel Jalkut
Personally I'm investing my energies into other stuff at this point and planning to do a "catch up" release after the sandbox deploys. It will be infinitely easier to accommodate the sandbox rules when we know with some certainty what they actually are.
Daniel
On Feb 11, 2012, at 11:37 AM, Peter Baumgartner wrote:
Florian Albrecht
nobody knows yet if Apple will stick to their dealine this time, but right now we have to assume they will. I know through direct conversation that they anticipate a flood of submissions towards the end of February, so they are pretty much aware of the problems and the fact that those problems hard (or even impossible) to solve for some developers. At least we tried to make sure that they are aware of our issues.
Independently of the deadline, I bet that there will be no official 'rules' published or otherwise communicated, explaining who gets which entitlements for what reason and especially which temporary entitlements for what amount time for which reason. I even assume that the internal rules will not be the same for two submissions of the same app, at least not for a while.
Through the last year we experienced several rather esoteric rejections of Boinx Software products for technology and solutions that had been there since day 1 of the App Store. They refined both checks and rules as time passed. Much in the same way I expect Apple to adjust sandboxing rules and exceptions. They want the App Store to be successful (by their own definition) and I am sure they'll relax rules if too many products they consider important will stop being available on the App Store and in the same way tighten rules if they see that many developer can adhere.
I am not trying to suggest that we should stop making iMedia sandbox-compliant, I'm only saying that there will never be a definitive from Apple as to how they'll accept it. Depending on numerous factors they may accept a non-XPC version initially, but don't rely on that for the future even if they will accept it once. I totally agree with Daniel that Ivan will not be the person deciding on the policy in the end.
My guess is that only sandboxed apps will survive in the long run and I also assume that the rules will even tighten in other areas as time passes.
Cheers,
f l o r i a n
Mike Abdullah
Mike.
Sent from my iPhone
On 11 Feb 2012, at 16:37, Peter Baumgartner <pe...@boinx.com> wrote:
> Hi Mike,
>
> Right after WWDC I did some sandboxing work. Dan showed the stuff I had done to Ivan at the Lion Dev Kitchen in Cupertino. He said that we would get the necessary (broad) entitlements for iMedia, but only if we factor them out into XPC bundles. So it is absolutely necessary that we do this work now, or iMedia won't have much of a future - i.e. unless Apple chooses to ditch it's plans for sandboxing at the last minute. But I guess that would be wishful thinking ;-)
>
> BTW, the entitlements for reading Music, Pictures, and Movies folders are not enough. We need to be able to read the *entire* file system. Folder parser for one requires that, and iTunes, iPhoto, Lightroom, or Aperture all have the ability to spread their media files all over the place, not just on a single volume, but on multiple volumes. Ivan understood these requirements and told us we would get the necessary temporary exception entitlement (but only if factored out to an XPC service).
And this is the bit I find strange: splitting out a service to gain a *temporary* entitlement. These cases are all relatively advanced use cases; the people that apple probably cares about least right now.
As it stands presently, Sandvox is pretty going to be forced to ask for read only access to the file system, regardless of iMedia. The problem that everybody's fairly desperately waiting on apple to solve: persistent access to individual files/folders. If we can have that, Sandvox no longer needs such a broad entitlement, and iMedia's folder parser can work again.
After that, the remaining problem is external media referenced by Aperture etc. Again it seems we need to wait on apple for a decent solution, rather than refactor in order to have a temporary solution.