• NeatNit@discuss.tchncs.de
    link
    fedilink
    arrow-up
    1
    ·
    7 months ago

    There’s always a risk of JavaScript breaking out of the sandbox and crap like that. Browser vendors do their best to protect against things like that but security is often a trade-off for speed and people like fast software, not to mention browsers are huge and complex and they’re going to have vulnerabilities. A browser’s whole job is to execute remote untrusted code, do you trust it that much to be flawless?

    … I mean, I don’t but I use it anyway so ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

        • PoolloverNathan@programming.dev
          link
          fedilink
          arrow-up
          2
          ·
          edit-2
          6 months ago

          Made a Nix library for this. For a simple setup you can just build this (untested) and run the result:

          import ./encase.nix {
            name = "firefox";
            rw.home.nathan = /home/nathan/home-for/firefox;
            # other dependencies it might need...
            tmp = /tmp; # fresh tmpfs for this sandbox
            network = true;
            command = pkgs.firefox;
          }
          

          It doesn’t have user isolation yet, so if it escapes the browser and the chroot (which doesn’t have a /proc unless you set proc = /proc;, and runs in a PID namespace either way) your files are still at risk. However, this is still pretty secure, and you can run the script itself as a different user (it creates a new UID namespace so chrooting can be done without root).