{"action":"closed","issue":{"url":"https://api.github.com/repos/VCVRack/Rack/issues/686","repository_url":"https://api.github.com/repos/VCVRack/Rack","labels_url":"https://api.github.com/repos/VCVRack/Rack/issues/686/labels{/name}","comments_url":"https://api.github.com/repos/VCVRack/Rack/issues/686/comments","events_url":"https://api.github.com/repos/VCVRack/Rack/issues/686/events","html_url":"https://github.com/VCVRack/Rack/issues/686","id":294744294,"node_id":"MDU6SXNzdWUyOTQ3NDQyOTQ=","number":686,"title":"[Discussion] Security Considerations","user":{"login":"bontric","id":6393673,"node_id":"MDQ6VXNlcjYzOTM2NzM=","avatar_url":"https://avatars1.githubusercontent.com/u/6393673?v=4","gravatar_id":"","url":"https://api.github.com/users/bontric","html_url":"https://github.com/bontric","followers_url":"https://api.github.com/users/bontric/followers","following_url":"https://api.github.com/users/bontric/following{/other_user}","gists_url":"https://api.github.com/users/bontric/gists{/gist_id}","starred_url":"https://api.github.com/users/bontric/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bontric/subscriptions","organizations_url":"https://api.github.com/users/bontric/orgs","repos_url":"https://api.github.com/users/bontric/repos","events_url":"https://api.github.com/users/bontric/events{/privacy}","received_events_url":"https://api.github.com/users/bontric/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":56,"created_at":"2018-02-06T12:38:34Z","updated_at":"2018-06-22T21:07:00Z","closed_at":"2018-06-22T21:07:00Z","author_association":"CONTRIBUTOR","body":"Since the topic has recently come up we should start to discuss how we can protect Rack users from potentially malicious 3rd party plugins. With an increasing user base, distributing malware induced plugins will become more interesting for attackers.\r\n\r\nAfter some discussion here is a summary naming valuable considerations:\r\n\r\n1) **Sandboxing** the whole application seems like a more reasonable approach. Optional or packaged sandboxing have been considered. @WIZARDISHUNGRY has already provided some valuable information regarding this. For security-minded people creating a guide or adding support might already prevent the initial concerns. \r\n\r\nSources regarding this:\r\n+ https://developer.apple.com/library/content/technotes/tn2312/_index.html\r\n+ https://www.malwaretech.com/2014/10/usermode-sandboxing.html\r\n+ https://developer.apple.com/library/content/qa/qa1483/_index.html\r\n+ https://www.chromium.org/Home/chromium-security/guts\r\n+ https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md\r\n+ https://chromium.googlesource.com/chromium/src/+/master/sandbox\r\n\r\n2) **[SAST](https://www.owasp.org/index.php/Source_Code_Analysis_Tools)** Might be an interesting option which might help to prevent unintentional security issues.  This does not affect the main concern of intentionally malicious plugins\r\n\r\n3) Official **plugin distribution** will be secured by authenticating publishers. \r\n**Note:** This does not prevent an attacker from faking an identity. Consider Google's Play Store which is packed with [data stealing](https://thehackernews.com/2017/12/google-playstore-malware.html)/[ad inducing](https://thehackernews.com/2017/12/google-playstore-malware.html) apps. There should be (and I guess @AndrewBelt  is also considering this)  quality checks regarding officially distributed plugins.\r\n\r\n4) The only somewhat realistic **architectural** approach to prevent malicious/faulty plugins from accessing\r\nthe user space  is [privilege separation](https://en.wikipedia.org/wiki/Privilege_separation) by running __all__ plugins in a non-privileged Process. **However:** This would require a very sophisticated and time intense overhaul of Racks current implementation. Therefore, it would require more than one developer working towards a clear goal to finish this in a reasonable amount of time. This is currently not feasible.\r\n\r\nAnd as Andrew stated:\r\n\r\n> I believe that downloading random binaries from the internet should put all the responsibility on you, which is acceptable if there is an official, accepted way of installing trusted plugins.\r\n\r\nI do agree with this argument, yet most users will have exactly zero understanding of the potential danger. Maybe the addition of a warning dialog before loading untrusted 3-rd party plugins might give those users and additional hint. \r\n\r\n## Original Comment:\r\n\r\n### Secure Architecture\r\nFrom a software design standpoint we can consider implementing a plugin system which tries to limit the privileges of any plugin by implementing [privilege separation](https://en.wikipedia.org/wiki/Privilege_separation). Right now I can come up with the following  two approaches, which may or may not be feasible:\r\n\r\n1) Run all plugins in a separate process with dropped privileges. Audio is passed from/to the main process via shared memory. The main process allows plugins to access files in a specific folder (e.g. for loading samples) by providing an interface communicating over shared memory/sockets.\r\n\r\n2) Similar to *1)* but each plugin is run in a separate process. Each cable is implemented by using shared memory. This might create an unfeasible overhead (I honestly don't know, so we might want to test such an approach) but adds additional security and stability (plugins can't crash the application)\r\n\r\nNote that there are a lot more things to consider when implementing this. Rendering and user interaction with plugins needs to be considered. In general this is quite a lot of work, but would improve on the current situation with VST/AU/etc.- plugins which do not consider security . \r\n\r\n###  Secure Plugin Infrastructure\r\n\r\nA simpler, regarding the implementation of Rack, approach to this issue is ensuring that plugins are supervised. This could be achieved by implementing checks for plugins (Rack only loads plugins which have a verified hash or something similar). The real downside of this is that for every version of every plugin someone would need to audit the source code of the plugin. With an increasing number of plugins this will become quite a lot of work. It's hard to estimate whether this would be feasible at all, but it might also be possible if we can find enough (trusted) people which will handle this work.\r\n\r\n\r\n### 3rd Party Applications\r\n\r\nAnother option is to advice users to use software like [firejail](https://firejail.wordpress.com/) or [nsjail](https://github.com/google/nsjail) as suggested in #638 when using untrusted 3rd party plugins. This, however, will not protect users which do not consider security, which is also the group of people most likely to download and use malicious plugins.\r\n\r\n\r\n**Note:** This is just a quick summary of thoughts I had regarding the plugin security issues. They by all means not thought through. It would be great if we can come up with other ideas and options as well, to figure out an applicable solution."}}
{"actor":{"display_login":"AndrewBelt"}}