[kzrdude]

The only component is an editor that runs some code automatically.

A python plugin for an editor would have the same problem - if it imports a python module for any reason, like code completion. Same problem of arbitrary code execution.

I think we should work on solutions. Sandboxing both for editor plugins and for regular rust builds, should become the norm.

[db48x]

Sandboxing isn’t necessary. Proper use of SELinux, which the Linux kernel in your computer already supports even if your distro doesn’t enable it, would already prevent any process other than ssh from reading your private key. The build system could run ssh and ssh would be allowed to read the key, but the key is still safe as long as ssh cannot be tricked into revealing it. Since that’s generally believed to be the case, no sandboxing is necessary.

If your distro doesn’t enable SELinux, or your distro’s SELinux policy doesn’t protect your ssh keys, then you need to upgrade. If you don’t use Linux, then you need to upgrade to Linux.

[aseipp]

SELinux is nothing but a maintenance burden for developers and users. There's a reason no major distro beyond the Fedora line that enables it by default, including the one I work one; it almost invariably frustrates users, has incomplete support for the workflows they use, and so they turn it off anyway. I literally turned off SELinux on my new ARM64 Fedora machine last week, because it prevented me from installing a third party binary (which I am a developer of.) That binary in turn needed its own ability to use namespacing support to sandbox applications (in a manner that works and offers enhanced security on any Linux distro, not just SELinux ones), etc. It's a non-starter.

> Since that’s generally believed to be the case, no sandboxing is necessary.

That's where you're wrong. It's necessary even if you believe it's not. It's been proven time and time again that this is the case and that the "belief" no flaws exist is wrong.

Sandboxing approaches that use techniques like namespaces, and capability security have become vastly, vastly more popular over the years on Linux, and they're going to keep getting more popular, precisely because they work where SELinux fails (that is, 98% of the running Linux systems and distros that actually exist). Browsers, WebAssembly, systems like Flatpak with "Portals" -- all of them have moved into capability-inspired and "component" sandboxing approaches, to achieve this level of security independent of the host operating system. If Chrome had decided to use SELinux instead of its own sandboxing approach, it's security model would be completely inferior to what it is today.

[db48x]

Don’t confuse the sandboxing a browser does with other types. I would never argue that a browser shouldn’t sandbox javascript. The kernel should also prevent the browser from reading your SSH keys as well, just in case :)

[mkesper]

We use SELinux at work. It's really a lot of work to check all requests whether they're legitimate or not.

[db48x]

No argument there. The one downside of any fine–grained security system is the work it takes to build and maintain the security policy.

[tux3]

Calling it a need to upgrade if I don't have SELinux is a little combative --- I'm perfectly happy with my AppArmor thankyouverymuch :)

[db48x]

I’ve not used AppArmor much, but I guess it’s at least better than nothing :)

[peq]

If I rememver correctly, the python plugin for vscode asks me whether I trust the project before running anything. At least that was the case when I last opened a Jupyter notebook in vscode.