Audio production on Linux, using proprietary audio plugins, is somewhat funny/interesting to see in the context of security.
I mean, there are a lot of recent efforts to put applications in containers, sandboxes, lots of talking about X11 being unsafe vs Wayland...
And then users just download and run arbitrary binary code from the internet 😅
Nothing against those that do this, it is just a bit funny to see from a security perspective.
@falktx I don't do music production but couldn't (shouldn't) hosts sandbox the plugins?
E.g. using https://landlock.io/
@pluto haha, I have bad news for you...
99% of DAWs and audio plugin hosts do no sandboxing or bridging.
But it's kinda expected, when we are dealing with 1000s of plugins that need to run in less than 0.5ms each. Dealing with context switching and thread sync across these many instances would waste time that could be better spent processing more plugins.
@pluto Bitwig does that, kinda. The engine is its own process and plugins go together with it, separate from the UI and session manager. This allows to protect against engine/plugin crashes. It's not really sandboxing though.
For true sandboxing flathub with audio plugins kinda does that right now, by loading plugins within that same sandbox. But it's quite inconvenient, apps from flathub do not see global/system-wide installed plugins (and if they do they break sandbox rules)
@falktx well then maybe rather sandbox the process as a whole. I'm getting somewhat curious to what the fallout would be of widely locking down say an Ardour (or maybe something simpler?) just before loading plugins.
No more arbitrary saving and loading files after that but it might make for a proof of concept.
From my understanding, the performance impact would be negligible, and only apply to those types of resource acquisition which landlock is actively filtering.