Anyone making "Sandbox-Safe" Audio Units?

[AdmiralQuality]

It does not verify whether or not the author employs a crackhouse full of rabid chimps as developers.

Hey, our customers pay good money too keep those chimps on crack!

Rest of points well taken. Everything is now Java. Great!

[Urs]

Urs, how did you pull it off? I assume you're still allowing 10.6.x?

We build using 10.5 SDK. I've only passed on what guys at former Emagic told me ("Works fine, loads/saves presets, can't register"). No idea what level of security they chose, I don't even know what those levels are (read that in George's post first time ever)

During the past few weeks we had *no* resources to install any Logic pre-release or tamper with any AU Lab settings whatsoever. We ordered a Mac Mini today and that'll be the first time we see Mavericks and a sandboxed AU host, if Rob or someone gets a free minute to mouse it out.

[AdmiralQuality]

Is anyone else here considering charging more for Mac versions in the future? I think it's very unfair that Windows users are expected to subsidize Mac development that takes 10 times longer.

[george]

No idea what level of security they chose, I don't even know what those levels are (read that in George's post first time ever)

This is what I got after trying to load Corona with GarageBand X:

After setting it and adding discoDSP folder as symlink to GarageBand sandbox Documents everything ran as expected.

I still have to figure how to reset that...

[AdmiralQuality]

No idea what level of security they chose, I don't even know what those levels are (read that in George's post first time ever)

This is what I got after trying to load Corona with GarageBand X:

After setting it and adding discoDSP folder as synlink to GarageBand sandbox Documents everything ran as expected.

I still have to figure how to reset that...

"Lower Security Settings"

[hibrasil]

you just have to click that button the once right to lower security settings? If that's the case then I am not going to sandbox.

[Jace-BeOS]

Self-contained plug-ins (a compressor with a few GUI resources stored in its bundle, say) should be just fine.

Anything complex with a file system browser (oops, did I say file system? Dirty word nowadays)? Pretty much screwed.

This is part of a push to make all software components self-contained on desktop and iOS, whether or not it's right for the component in question.

For Angry Birds? Sure. Easy & side-effect-free install and uninstall, and no chance of it doing something it shouldn't.

For XCode? Straight up dumb. Making the Mac OS X SDK part of the app bundle is pure stupid.. they've had to brain-damage their own app to make it fit the model. The SDK and the IDE are different components for different purposes & so belong under different hierarchies. (As an aside.. if you're a developer who cares about where all your intermediates & build products get put, they've also made that more difficult. Sure, you can override it, but the default setting show what the intent is: You don't need to know.)

The long term direction and intent is pretty clear, though. Everything on the desktop goes self-contained. Browsing the file-system is no longer to be encouraged, because users have no business thinking in terms of the file-system. User data belongs in the Cloud, whether you like it or not, because Mother knows best, and you, little user, cannot be trusted to look after your own data.

You know what this sounds a lot like? All those command line jockeys and DOS/Unix geeks and developers who swore up and down that there's no reason to have a GUI. They were wrong, too.

As a developer, you want access to internals. As a user, there's no reason to (provided the system does what it's supposed to do, unlike MS's first attempt at WYSIWYG web editing). Seriously, ask yourself if you are the average user or a specialist. Even as a tech person who grew up with this crap, I know full well that it IS crap to a user.

You're not making product to sell to tech geeks. You're making tools for users to do specific tasks.

Change happens and the computer industry has long needed to come out of its infancy and stop being a pile of parts strapped together with the guts hanging out, demanding specialized knowledge for regular use and maintenance. Even developers can benefit from a better working environment. This isn't like the slippery slope of rights losses in the USA. The computer is supposed to be a tool and it's high time they started actually behaving like what they claim to be.

[AdmiralQuality]

Self-contained plug-ins (a compressor with a few GUI resources stored in its bundle, say) should be just fine.

Anything complex with a file system browser (oops, did I say file system? Dirty word nowadays)? Pretty much screwed.

This is part of a push to make all software components self-contained on desktop and iOS, whether or not it's right for the component in question.

For Angry Birds? Sure. Easy & side-effect-free install and uninstall, and no chance of it doing something it shouldn't.

For XCode? Straight up dumb. Making the Mac OS X SDK part of the app bundle is pure stupid.. they've had to brain-damage their own app to make it fit the model. The SDK and the IDE are different components for different purposes & so belong under different hierarchies. (As an aside.. if you're a developer who cares about where all your intermediates & build products get put, they've also made that more difficult. Sure, you can override it, but the default setting show what the intent is: You don't need to know.)

The long term direction and intent is pretty clear, though. Everything on the desktop goes self-contained. Browsing the file-system is no longer to be encouraged, because users have no business thinking in terms of the file-system. User data belongs in the Cloud, whether you like it or not, because Mother knows best, and you, little user, cannot be trusted to look after your own data.

You know what this sounds a lot like? All those command line jockeys and DOS/Unix geeks and developers who swore up and down that there's no reason to have a GUI. They were wrong, too.

As a developer, you want access to internals. As a user, there's no reason to (provided the system does what it's supposed to do, unlike MS's first attempt at WYSIWYG web editing). Seriously, ask yourself if you are the average user or a specialist. Even as a tech person who grew up with this crap, I know full well that it IS crap to a user.

You're not making product to sell to tech geeks. You're making tools for users to do specific tasks.

Change happens and the computer industry has long needed to come out of its infancy and stop being a pile of parts strapped together with the guts hanging out, demanding specialized knowledge for regular use and maintenance. Even developers can benefit from a better working environment. This isn't like the slippery slope of rights losses in the USA. The computer is supposed to be a tool and it's high time they started actually behaving like what they claim to be.

How long before commodity computers can no longer be used to create the software they run? (See any iOS and Android device.) What will us "tech geeks" use then to actually CREATE things on, once the computer becomes a consumer-only device?

It's an unmaintainable pattern.

[Crandall1]

Okay. Thanks to Sean Costello, we have found that all Audio Damage products (which, for the record, are built against the 10.6 SDK) work flawlessly in both Garageband X and Logic X Sandboxed. What we discovered is the following:

Logic X Sandboxed and Garageband X necessarily have their own libraries (which can be found in /Library/Containers/com.apple.logic10/Data/ and /Library/Containers/com.apple.garageband10/Data/ respectively, which won't surprise any iOS developers.)

Anything that your plug-in would put in Application Support needs to be here as well; on first instance, the AU manager attempts to copy the plug-in's Application Support documents to its own Application Support folder. In our case, for whatever reason, the copy protection files (which we store in App Support) get copied with zero bytes.

So, the solution in our case is to copy the contents of ~/Library/Application Support/Audio Damage to the /Audio Damage folder in the appropriate application. After that, the plugs work as expected.

Note that in Mavericks you can't actually see any of these files in the normal Finder. You need to use something like EasyFind to locate them. (Just search com.audiodamage and they'll pop up. We'll make an Applescript to do the task for the short term, and eventually figure out how to make the whole thing work correctly.

Hope this gives a clue for any other devs that are having trouble.

[Jace-BeOS]

If an app is sandboxed it could still be taken over from within, say by some data execution hack.

Take something like Flash Player, an app which absolutely should be sandboxed. Or possibly burned, crushed, boiled in acid and then thrown in to the heart of a neutron star.

It's digitally signed. All that does is verify that the binary code hasn't been tampered with by anyone besides the author. It does not verify whether or not the author employs a crackhouse full of rabid chimps as developers. And if the code executes user-supplied content off the web, or has such a complex parse structure that it might as well be executing arbitrary code (PDF a good case in point), there's still lots of holes where a buffer overflow might allow the app to execute arbitrary code inside the sandbox.

That's where the sandbox comes in to effect - it stops the arbitrary code getting any further (as do, to some extent, protected memory, and least-privilege user accounts).

But what that tech note says is, Apple fixed a security flaw which would have allowed a compromised app to break outside its sandbox, by running an external process, because malware could then break out of the sandbox to, say, "exec rm -rf ~/*".

Which is fine, in the context of a sandbox. It's the right way to go about things for apps which run arbitrary code from all over the web, which are installed everywhere and present a huge attack vector. But pro audio software just isn't like that.. even if a suitable buffer-overrun flaw were to exist, and somebody were to maliciously craft a GarageBand file that could pwn a machine, how many people would get infected? Not enough to be worth it, surely.. bearing in mind those kind of hacks are incredibly time-consuming to pull off in the first place.

This was a hilarious post and was amusing. But I have to take issue with your position that these areas are somehow not worth protecting. Why would you ever willingly NOT protect anything vulnerable? The whole point of what exploits do is to attack vulnerabilities wherever they may be found.

Do you willingly engage in risky behavior because the chances of death or injury are considered unlikely (an opinion, if not a statistical fact)? If so, great for you, but NOT something you have the right to choose for others. You're a developer and that means you're making product for other people.

If we have an opportunity to address long standing design vulnerably in this industry, why would you not want to do so? It's really high time that computers stop being given special excuse to behave badly, including when assaulted by external parties.

The design of software and hardware has been driven by feature wishes and the inability to do things ideally, from the ground-up, due to technological limitations and a simple lack of experience with the [formerly new] world of computing. Now that we can overcome most of these limits and all these design mistakes (which might not have been perceived as such back in their days of conception) have been learned, why aren't we embracing the opportunity to make it right?

Because we don't like change and doing things differently from what we're used to?

Not an acceptable excuse.

I hear your frustration with having your work complicated by changing development APIs, SDKs, and policies. I appreciate it. But at the same time, I really feel you folks need to appreciate the other end of the stick where your customers live. Developers and users are rather mutually dependent. It is not valuable to excuse computer industry flaws by putting the responsibility on the user to be specially trained to operate the technology. The expectation of computers to be a specialized technical gadget only operated by trained professionals is long out of date, yet the programmers from that era still persist in thinking that way. If you want normal people to buy your products, they should be accessible to them.

BTW: mocking GarageBand doesn't really reflect well on you guys. You should be glad that GarageBand has brought you more customers and has opened the door to these tools being used by more people. There is a time and a place to criticize a tool for lacking professional features, such as Apple's recent gutting of Pages and Numbers on Mac to make parity with iOS versions. But GarageBand never claimed to be a professional's tool, and it has likely done favors to your market if you sell plugins on the Mac at all.

[AdmiralQuality]

If an app is sandboxed it could still be taken over from within, say by some data execution hack.

Take something like Flash Player, an app which absolutely should be sandboxed. Or possibly burned, crushed, boiled in acid and then thrown in to the heart of a neutron star.

It's digitally signed. All that does is verify that the binary code hasn't been tampered with by anyone besides the author. It does not verify whether or not the author employs a crackhouse full of rabid chimps as developers. And if the code executes user-supplied content off the web, or has such a complex parse structure that it might as well be executing arbitrary code (PDF a good case in point), there's still lots of holes where a buffer overflow might allow the app to execute arbitrary code inside the sandbox.

That's where the sandbox comes in to effect - it stops the arbitrary code getting any further (as do, to some extent, protected memory, and least-privilege user accounts).

But what that tech note says is, Apple fixed a security flaw which would have allowed a compromised app to break outside its sandbox, by running an external process, because malware could then break out of the sandbox to, say, "exec rm -rf ~/*".

Which is fine, in the context of a sandbox. It's the right way to go about things for apps which run arbitrary code from all over the web, which are installed everywhere and present a huge attack vector. But pro audio software just isn't like that.. even if a suitable buffer-overrun flaw were to exist, and somebody were to maliciously craft a GarageBand file that could pwn a machine, how many people would get infected? Not enough to be worth it, surely.. bearing in mind those kind of hacks are incredibly time-consuming to pull off in the first place.

This was a hilarious post and was amusing. But I have to take issue with your position that these areas are somehow not worth protecting. Why would you ever willingly NOT protect anything vulnerable? The whole point of what exploits do is to attack vulnerabilities wherever they may be found.

Do you willingly engage in risky behavior because the chances of death or injury are considered unlikely (an opinion, if not a statistical fact)? If so, great for you, but NOT something you have the right to choose for others. You're a developer and that means you're making product for other people.

If we have an opportunity to address long standing design vulnerably in this industry, why would you not want to do so? It's really high time that computers stop being given special excuse to behave badly, including when assaulted by external parties.

The design of software and hardware has been driven by feature wishes and the inability to do things ideally, from the ground-up, due to technological limitations and a simple lack of experience with the [formerly new] world of computing. Now that we can overcome most of these limits and all these design mistakes (which might not have been perceived as such back in their days of conception) have been learned, why aren't we embracing the opportunity to make it right?

Because we don't like change and doing things differently from what we're used to?

Not an acceptable excuse.

I hear your frustration with having your work complicated by changing development APIs, SDKs, and policies. I appreciate it. But at the same time, I really feel you folks need to appreciate the other end of the stick where your customers live. Developers and users are rather mutually dependent. It is not valuable to excuse computer industry flaws by putting the responsibility on the user to be specially trained to operate the technology. The expectation of computers to be a specialized technical gadget only operated by trained professionals is long out of date, yet the programmers from that era still persist in thinking that way. If you want normal people to buy your products, they should be accessible to them.

BTW: mocking GarageBand doesn't really reflect well on you guys. You should be glad that GarageBand has brought you more customers and has opened the door to these tools being used by more people. There is a time and a place to criticize a tool for lacking professional features, such as Apple's recent gutting of Pages and Numbers on Mac to make parity with iOS versions. But GarageBand never claimed to be a professional's tool, and it has likely done favors to your market if you sell plugins on the Mac at all.

And the audio software products you've produced are...? This is the Dev board. The opinion of Apple fanboy-consumers is irrelevant here.

[george]

Logic X Sandboxed and Garageband X necessarily have their own libraries (which can be found in /Library/Containers/com.apple.logic10/Data/ and /Library/Containers/com.apple.garageband10/Data/ respectively, which won't surprise any iOS developers.)

Anything that your plug-in would put in Application Support needs to be here as well; on first instance, the AU manager attempts to copy the plug-in's Application Support documents to its own Application Support folder. In our case, for whatever reason, the copy protection files (which we store in App Support) get copied with zero bytes.

So, the solution in our case is to copy the contents of ~/Library/Application Support/Audio Damage to the /Audio Damage folder in the appropriate application. After that, the plugs work as expected.

Using symlinks should work too. All our installers are using them already.

[Jace-BeOS]

Is anyone else here considering charging more for Mac versions in the future? I think it's very unfair that Windows users are expected to subsidize Mac development that takes 10 times longer.

Microsoft is surely headed in the same direction with Windows RT and Surface devices. You might as well get used to the new concepts because Windows will be continuing to change to compete with Apple's market attention, especially in a way that puts perception of user friendliness ahead of developer comfort. Not that I expect Microsoft to go about it in the same way, or in a good way for users or developers. But look at what they've done in the last year and what they claim to be doing next. Backwards compatibility has long been their winning tactic, but the industry is changing and it's going to keep changing.

The long history of static consistency looks to be coming to a gradual close.

• VST is getting closer to Cubase's internal ideals than a universal plugin standard, and why would we not expect Steinberg to recognize they've been aiding their competitors with the VST SDK all these years? You guys have been ranting about the VST3 SDK quite a lot, but are you going to stop developing VST entirely as a consequences of Steinberg's changes, or fall in line, however grudgingly, because you have to do so or stop marketing plugins?

• Mac is learning tricks from the walled garden successes of iOS.

• Microsoft is learning Apple was right, again, about what regular people want, and scrambling to create product that gives the same impression to consumers.

• Hardware is getting more focused on specific use and portability, rather than complexity and power.

• People don't value intangibles even as much as they once did (which wasn't a lot), and money is scarce.

• Etc.

Move along with the changes or stop progressing, you know? If Mac development doesn't provide you with the income you require, then that's a business decision to make. However, remember VST3 is your Windows future, and don't expect Windows to maintain its backwards compatibility indefinitely.

Again, I hear the frustration, but I would think developers would have long ago resigned themselves to change being the norm, especially those who are developing add-ons to other people's products, through other people's private SDKs. Isn't this just the nature of the beast you chose to ride? Find the best in it instead of fighting it. Bitch about it, I guess, but not to the point of trying to slander the choices of the masters you ultimately serve (users and the owners of the SDKs you develop in).

But WTF do I know. I'm just a stupid user.

[AdmiralQuality]

Is anyone else here considering charging more for Mac versions in the future? I think it's very unfair that Windows users are expected to subsidize Mac development that takes 10 times longer.

Microsoft is surely headed in the same direction with Windows RT and Surface devices. You might as well get used to the new concepts because Windows will be continuing to change to compete with Apple's market attention, especially in a way that puts perception of user friendliness ahead of developer comfort.

Again, who the hell are you?

Not that I expect Microsoft to go about it in the same way, or in a good way for users or developers. But look at what they've done in the last year and what they claim to be doing next. Backwards compatibility has long been their winning tactic, but the industry is changing and it's going to keep changing.

Spoken like a true Apple fanboy. Just like I said.

The long history of static consistency looks to be coming to a gradual close.

• VST is getting closer to Cubase's internal ideals than a universal plugin standard, and why would we not expect Steinberg to recognize they've been aiding their competitors with the VST SDK all these years? You guys have been ranting about the VST3 SDK quite a lot, but are you going to stop developing VST entirely as a consequences of Steinberg's changes, or fall in line, however grudgingly, because you have to do so or stop marketing plugins?

So, by enabling their USERS to use products from other companies freely with their products, that to you is enabling their competitors?

You should run out and buy a new ProTools system if you like getting the shaft that much.

• Mac is learning tricks from the walled garden successes of iOS.

A device that's not capable of programming for itself.

• Microsoft is learning Apple was right, again, about what regular people want, and scrambling to create product that gives the same impression to consumers.

You're in a complete fantasy world if you think Microsoft take programming lessons from Apple!

• Hardware is getting more focused on specific use and portability, rather than complexity and power.

• People don't value intangibles even as much as they once did (which wasn't a lot), and money is scarce.

• Etc.

Move along with the changes or stop progressing, you know? If Mac development doesn't provide you with the income you require, then that's a business decision to make. However, remember VST3 is your Windows future, and don't expect Windows to maintain its backwards compatibility indefinitely.

Again, I hear the frustration, but I would think developers would have long ago resigned themselves to change being the norm, especially those who are developing add-ons to other people's products, through other people's private SDKs. Isn't this just the nature of the beast you chose to ride? Find the best in it instead of fighting it. Bitch about it, I guess, but not to the point of trying to slander the choices of the masters you ultimately serve (users and the owners of the SDKs you develop in).

But WTF do I know. I'm just a stupid user.

Yes, you are. PARTICULARLY!

[valhallasound]

I installed a few plugins today on GarageBand X in 10.9. I installed Eos (which is how I figured out the stuff Chris Randall mentioned above) and my own plugins. None of my plugins are currently sandbox safe. The results:

- The plugin authorizations for Valhalla DSP plugins (mine) were not found by GarageBand. I had to reauthorize the plugins, using the keyfile. Once this was done, things worked fine.

- I did a search on my computer using EasyFind (Finder is now utterly worthless), and found that a new instance of the ValhallaRoom.settings file was located at

./Library/Containers/com.apple.garageband10/Data/Library/Preferences

All my other plugins had new .settings files there after the reauthorizations. Normally, the .settings files are located at

./Library/Preferences

- I compile against the 10.5 SDK, and target 10.4. One of my plugins that I installed (ValhallaShimmer) was compiled in December 2010. These plugins ran fine in GarageBand X on OS 10.9. I am hoping that the same holds true for Logic X.

I'm in the middle of AAX ports (getting close to the end of AAX porting for a couple of the plugins), and these require Apple code signing certificates, as part of the Pace Eden signing. I will probably add code signing to the other OSX plugins, just to keep things from having to be reauthorized again, having to explain how to turn off Gatekeeper, etc. I am going to continue to compile against the OS 10.5 SDK as long as it is feasible, so older Apple computers can be supported. I'll need to give up on PPC support at some point, but I would piss off a lot of users if I was no longer supporting Snow Leopard. Hopefully the code signing won't screw up the installs on older Macs.

Sean Costello