7 ms·

Sandboxed code is not slower than unsandboxed code

yjftsjthsd-h 5y ago
Really? It seems like there should be some overhead ex. to verify whether each operation is allowed. Or does it not work like that?
- vngzs 5y ago
  The modern Linux kernel allows you to sandbox applications natively. There are tools that make this easy to set up, for instance [1]. [0]: https://blog.cloudflare.com/sandboxing-in-linux-with-zero-lines-of-code/ https://blog.cloudflare.com/sandboxing-in-linux-with-zero-li... [1]: https://firejail.wordpress.com/ https://firejail.wordpress.com/
  - junon 5y ago
    Those sandboxes are certainly not free to set up (internal kernel locking) fwiw.
  - rjzzleep 5y ago
    I use firejail and have the standard redirects in /usr/local/bin for most firejail supported applications, but the performance hit is definitely noticeable. I'm on an i7-8650U on my laptop with 16G ram. Sandboxing _can_ be without overhead, but in the case of firejail it's definitely not the case.
    - rfoo 5y ago
      > performance hit is definitely noticeable Could you please name which application, and how do you notice it?
      - rjzzleep 5y ago
        I notice it by how long it takes to start applications when I run them through firejail vs. when I run them directly. I don't know if it also makes a difference during execution. EDIT: it's kinda amusing to get downvoted on this. a) There's no performance issue. Just use linux sandboxes b) There are these possible performance hits c) I use those sandboxes and I have observe X performance issues. a) Your performance issues are not valid performance issues, because I say so. Ok, gotcha
        swiley 5y ago
        That's really a caching issue. Normally dynamically linked bins share a lot of code pages (many are already loaded) due to SOs. In jailed apps these are duplicated and have to be loaded again for each app.
        sokoloff 5y ago
        It’s a caching issue that manifests itself as a performance difference, which is all GP claimed.
      - hjek 5y ago
        I'm using a low-spec laptop, so I usually notice these things before others. With Firejail I don't notice any performance hit at all on any of the apps I've used: Telegram, various windows games under Wine, Chromium.
- KMag 5y ago
  To expand on vngzs's post, many key Linux syscalls (such as opening a socket/file descriptor) always check if a bit is set in a capabilities bitfield, so the only extra overhead is the one-time syscall to drop some set of capabilities. Now, there is some overhead in forking a child process to have different capabilities than the parent, and some overhead in using a pipe/shared memory to communicate between the sandboxed child and the parent, but that overhead should be tiny compared to the work of decoding compressed video, etc.
- DyslexicAtheist 5y ago
  there is some overhead depending of how you define isolation. seccomp has very little impact but it's not 0: https://wiki.tizen.org/Security:Seccomp#Performance_Analysis https://wiki.tizen.org/Security:Seccomp#Performance_Analysis firejail or systemd isolation techniques (using a variety of methods such as mounting a private version of directories or initiating ACL's at application start) are extremely lightweight but not 0. Most processes (regardless of desktop or server) usually live long enough (more than a few seconds anyway) to justify any theoretic impact. Even firejail on an ancient desktop system will not change things so that it's noticeable by a user imo.
wolverine876 5y ago
Speaking theoretically: If you want to isolate an application, it seems you need extra resources to run the isolation functions, to handle any trade-offs they introduce (it's hard to believe it's zero), and to reproduce needed functionality and services that are outside the isolated space. Essentially, I'm imagining a bunch of isolated VMs. How is that wrong in practice?
- iczero 5y ago
  On Linux, namespaces and seccomp have minimal overhead. seccomp can filter syscalls directly, so if you just need to convert formats, you could load the library in a helper process and drop privileges. Sure the helper process would require more resources, but it shouldn't take much. For more sophisticated isolation, Linux namespaces can be used. Out of boredom, I started 400 containers with podman running only bash in Ubuntu. It used less than 1 GB of RAM in total. podman is likely overkill if you just want sandboxing, however. I'm sure there are still tradeoffs to containerization but at least the overhead is minimal.
- michaelt 5y ago
  There's a bunch of isolation that you're already paying the price of. Your OS already has a layer that checks, when a process tries to open a file or access a bit of hardware, whether you have permission to access it. Your CPU has a layer that checks, when you try to read or write a given memory address, whether you have the right permissions. And so on. A lot of sandboxing amounts to making those existing checks more restrictive - telling the OS "If this program running as John Doe asks to open a file, instead of treating it like John Doe treat it like someone with no files at all" - which is no slower than what the OS was doing anyway. The sandboxing that comes with performance penalties is generally doing more than just sandboxing - for example, Ubuntu's 'snaps' have sandboxing, but they also duplicate a bunch of libraries for compatibility reasons.

Really? It seems like there should be some overhead ex. to verify whether each operation is allowed. Or does it not work like that?

vngzs 5y ago
The modern Linux kernel allows you to sandbox applications natively. There are tools that make this easy to set up, for instance [1]. [0]: https://blog.cloudflare.com/sandboxing-in-linux-with-zero-lines-of-code/ https://blog.cloudflare.com/sandboxing-in-linux-with-zero-li... [1]: https://firejail.wordpress.com/ https://firejail.wordpress.com/
- junon 5y ago
  Those sandboxes are certainly not free to set up (internal kernel locking) fwiw.
- rjzzleep 5y ago
  I use firejail and have the standard redirects in /usr/local/bin for most firejail supported applications, but the performance hit is definitely noticeable. I'm on an i7-8650U on my laptop with 16G ram. Sandboxing _can_ be without overhead, but in the case of firejail it's definitely not the case.
  - rfoo 5y ago
    > performance hit is definitely noticeable Could you please name which application, and how do you notice it?
    - rjzzleep 5y ago
      I notice it by how long it takes to start applications when I run them through firejail vs. when I run them directly. I don't know if it also makes a difference during execution. EDIT: it's kinda amusing to get downvoted on this. a) There's no performance issue. Just use linux sandboxes b) There are these possible performance hits c) I use those sandboxes and I have observe X performance issues. a) Your performance issues are not valid performance issues, because I say so. Ok, gotcha
      - swiley 5y ago
        That's really a caching issue. Normally dynamically linked bins share a lot of code pages (many are already loaded) due to SOs. In jailed apps these are duplicated and have to be loaded again for each app.
        sokoloff 5y ago
        It’s a caching issue that manifests itself as a performance difference, which is all GP claimed.
    - hjek 5y ago
      I'm using a low-spec laptop, so I usually notice these things before others. With Firejail I don't notice any performance hit at all on any of the apps I've used: Telegram, various windows games under Wine, Chromium.
KMag 5y ago
To expand on vngzs's post, many key Linux syscalls (such as opening a socket/file descriptor) always check if a bit is set in a capabilities bitfield, so the only extra overhead is the one-time syscall to drop some set of capabilities. Now, there is some overhead in forking a child process to have different capabilities than the parent, and some overhead in using a pipe/shared memory to communicate between the sandboxed child and the parent, but that overhead should be tiny compared to the work of decoding compressed video, etc.
DyslexicAtheist 5y ago
there is some overhead depending of how you define isolation. seccomp has very little impact but it's not 0: https://wiki.tizen.org/Security:Seccomp#Performance_Analysis https://wiki.tizen.org/Security:Seccomp#Performance_Analysis firejail or systemd isolation techniques (using a variety of methods such as mounting a private version of directories or initiating ACL's at application start) are extremely lightweight but not 0. Most processes (regardless of desktop or server) usually live long enough (more than a few seconds anyway) to justify any theoretic impact. Even firejail on an ancient desktop system will not change things so that it's noticeable by a user imo.

wolverine876 5y ago

Speaking theoretically: If you want to isolate an application, it seems you need extra resources to run the isolation functions, to handle any trade-offs they introduce (it's hard to believe it's zero), and to reproduce needed functionality and services that are outside the isolated space. Essentially, I'm imagining a bunch of isolated VMs. How is that wrong in practice?

iczero 5y ago
On Linux, namespaces and seccomp have minimal overhead. seccomp can filter syscalls directly, so if you just need to convert formats, you could load the library in a helper process and drop privileges. Sure the helper process would require more resources, but it shouldn't take much. For more sophisticated isolation, Linux namespaces can be used. Out of boredom, I started 400 containers with podman running only bash in Ubuntu. It used less than 1 GB of RAM in total. podman is likely overkill if you just want sandboxing, however. I'm sure there are still tradeoffs to containerization but at least the overhead is minimal.
michaelt 5y ago
There's a bunch of isolation that you're already paying the price of. Your OS already has a layer that checks, when a process tries to open a file or access a bit of hardware, whether you have permission to access it. Your CPU has a layer that checks, when you try to read or write a given memory address, whether you have the right permissions. And so on. A lot of sandboxing amounts to making those existing checks more restrictive - telling the OS "If this program running as John Doe asks to open a file, instead of treating it like John Doe treat it like someone with no files at all" - which is no slower than what the OS was doing anyway. The sandboxing that comes with performance penalties is generally doing more than just sandboxing - for example, Ubuntu's 'snaps' have sandboxing, but they also duplicate a bunch of libraries for compatibility reasons.