Anyone making "Sandbox-Safe" Audio Units?

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

I have managed to get Corona working with GarageBand X after spending all the morning with it, but still requires to "Lower Security Settings". Hope to "fix" that ASAP.

Probably "fixing" it will require to renew the Mac Developer Program and rewrite all file I/O calls.

Post

Hmmm. I'm silghtly miffed. I don't really have the time or motivation to deal with this right now.

I wonder why we had to codesign. They haven't prevented code with wrong signatures to execute. This would have been much more useful to "trust" software than crippling it by sandboxing.

Post

Urs wrote:Hmmm. I'm silghtly miffed. I don't really have the time or motivation to deal with this right now.

I wonder why we had to codesign. They haven't prevented code with wrong signatures to execute. This would have been much more useful to "trust" software than crippling it by sandboxing.
Well, that'll clearly be the next big change you'll have to waste resources on coping with, wont it. :bang:
my other modular synth is a bugbrand

Post

There are a couple of things to do to make an Audio Unit sandbox safe, and file system is (unfortunately) not necessarily the biggest deal!

The first thing is that you have to support the new AudioUnit APIs introduced in Mac OSX Lion (10.7), to get rid of the "old" component manager, considered as unsafe. The problem is that this requires you to compile with the 10.7 SDK, which breaks 10.5 and 10.6 compatibility if you are using C++ standard libraries (which most of us do). So that's a no go for the moment: we have more customers using 10.6 than sandbox-aware ones.

The second is indeed to manage file system access and deprecated APIs properly... It can be a big deal if you need access to resources outside of the sandbox, if you do not want to prompt 200 file system boxes to let the user choose where to store data...

It looks like Apple still has some work on its plate to prevent Pro users from avoiding Macs in the future :-(.

I guess it's a good time for all of us to file tons of bug reports with Garage Band X, which seems to be a test for Apple before they also migrate the big one, Logic Pro.

Post

Blue Cat Audio wrote: The first thing is that you have to support the new AudioUnit APIs introduced in Mac OSX Lion (10.7), to get rid of the "old" component manager, considered as unsafe. The problem is that this requires you to compile with the 10.7 SDK, which breaks 10.5 and 10.6 compatibility if you are using C++ standard libraries (which most of us do). So that's a no go for the moment: we have more customers using 10.6 than sandbox-aware ones.
I'm actually working on an AU right now, and I'm compiling fine with the 10.8 SDK using the new component manager, and everything seems to be up and running. Granted, this plug-in doesn't require any resources outside of its bundle for the moment, so that may be a factor..

Post

Like Urs, I have more than enough on my plate without dealing with this.

But if security really was the issue, then it seems to me that there was a far simpler solution, Apple could have added a facility to have a codesigned "resources required" file in the bundle, no code changes would have been needed then.

So I fear the theories that they're trying to push people in the direction of their "everything on the cloud" dream may well be true... which probably means once we've got our plugins working in a sandbox, they'll make some other change that gives us more work.

Post

JonHodgson wrote: So I fear the theories that they're trying to push people in the direction of their "everything on the cloud" dream may well be true... which probably means once we've got our plugins working in a sandbox, they'll make some other change that gives us more work.
Their own sample AUs don't even work without modifications to the code/build process. They build fine, but won't show up in any host that I tried until I got in there and tinkered..

Post

Angus_FX wrote: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.
:tu: :tu: :tu:

Post

So if I'm understanding Mr. Blue Cat correctly, setting the canBeSandboxed flag (or whatever the hell it's called) in info.plist, plus building against 10.7, will get us working for Logic X and Garageshit X?

As he said, this is no-deal, as we have _tons_ of customers on 10.6.8 still. Urs, how did you pull it off? I assume you're still allowing 10.6.x?

Post

Is there not just a setting users will be able to change to turn off sandboxing? If so, I'd expect 99% of audio host users will do exactly that.

The nerve of people, wanting to write freely on the storage devices they bought and own.

Post

From a tech note just posted on the Apple site:-
Description: The LaunchServices interface for launching an application allowed sandboxed apps to specify the list of arguments passed to the new process. A compromised sandboxed application could abuse this to bypass the sandbox. This issue was addressed by disallowing sandboxed applications from specifying arguments.
So if your plug-in wants to spawn any additional processes.. say for licensing, or some indexing utility, or analysis, or launch a browser at a help URL?

You can't.

Or at least, you can't pass any arguments to the spawned program.

Again, fine for cheesy little games. I don't want them installing Ask Toolbar behind my back either. For a professional audio application? Come on.
This account is dormant, I am no longer employed by FXpansion / ROLI.

Find me on LinkedIn or elsewhere if you need to get in touch.

Post

Angus_FX wrote:From a tech note just posted on the Apple site:-
Description: The LaunchServices interface for launching an application allowed sandboxed apps to specify the list of arguments passed to the new process. A compromised sandboxed application could abuse this to bypass the sandbox. This issue was addressed by disallowing sandboxed applications from specifying arguments.
So if your plug-in wants to spawn any additional processes.. say for licensing, or some indexing utility, or analysis, or launch a browser at a help URL?

You can't.

Or at least, you can't pass any arguments to the spawned program.

Again, fine for cheesy little games. I don't want them installing Ask Toolbar behind my back either. For a professional audio application? Come on.
WTF is "a compromised sandboxed application"???

Geezuz Kripes...

Post

Compromised = taken over by malware or hackers. You know, all those l33t krues trying to pwn peoples' systems worldwide through a buffer overflow in an audio plug-in that sold a couple of hundred copies some time in 2008.
This account is dormant, I am no longer employed by FXpansion / ROLI.

Find me on LinkedIn or elsewhere if you need to get in touch.

Post

Angus_FX wrote:Compromised = taken over by malware or hackers. You know, all those l33t krues trying to pwn peoples' systems worldwide through a buffer overflow in an audio plug-in that sold a couple of hundred copies some time in 2008.
But if it's sandboxed, how can it be taken over? Kind of the whole point, isn't it?

Doesn't successful sandboxing require Apple's stamp of approval? So you know the binary is legit? And how can something already running in a sandbox take over the system, even through a buffer overrun or similar exploit? If it can, then it's not really a sandbox. More like a sandbox with a cat turd buried somewhere in it.

Post

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 account is dormant, I am no longer employed by FXpansion / ROLI.

Find me on LinkedIn or elsewhere if you need to get in touch.

Post Reply

Return to “DSP and Plugin Development”