1. 13
#!/bin/sh

set -e

temp_dir=$(mktemp -d --suffix=.firefox)
mkdir -p $temp_dir
HOME=$temp_dir firefox $@
rm -rf $temp_dir

I’m sorta weirded out by having a script that deletes $HOME. It’s probably fine. An even simpler alternative: HOME=/dev/shm firefox

Any Firefox experts know if this is a bad idea?

  1.  

  2. 6

    You can tell Firefox to use a profile (-profile) and delete that profile when you’re done. Or you can use Firefox’s excellent profile management tools. Or any of the many extensions.

    A custom $HOME that you delete after should work but is pretty hacky.

    1. 4

      Yeah, that whole $HOME remaping is actually getting me off, while Firefox only maintains its profile at ~/.mozilla/firefox/*.profile, no other XDG directories are lost.

    2. 10

      It could be just one-liner:

      firefox --profile $(mktemp -d --suffix=.fx) --new-instance ; rm -r /tmp/*.fx

      1. 6

        Unclear what problem you’re solving. Firefox shouldn’t write anywhere else than the profile directory (see @jefftk’s comment). If you don’t want it to access your user configs in ~/. config. you can redirect $HOME though. But maybe you also want to chroot then?

        If you want to separate all sorts of history and site data and settings and extensions and password storage etc, use different profiles. If you want separate cookie jars (e.g. online identifies) to work in parallel, use the Multi Account Containers Extension.

        1. 8

          The problem this solves is that some websites are now detecting private mode browsing, and using it as an opportunity to be a dick.

          1. 6

            Ugh, that’s bad. Can you give an example of those?

            1. 10

              Nytimes does private mode detection as part of their paywall.

            2. 4

              How do they detect it, and how are they being a dick? I’ve honestly never noticed anything weird in private browsing mode, but I don’t use it all that often either.

          2. 3

            I have a very similar one, possibly with a tad better error handling (not that it matters much here):

            #!/bin/bash
            
            finish() {
                rm -rf "$TMP"
                exit
            }; trap finish EXIT INT TERM
            TMP="$(mktemp -d -t firefox.XXXXXX --tmpdir=/tmp)"
            
            env HOME="$TMP" firefox -no-remote "$@"
            

            My observations:

            1. OP’s script won’t clean up after itself if this Firefox gets killed or otherwise exits in less than ideal manner.
            2. It could use quotes around $@ for the argument list for proper whitespace handling.
            3. Without -no-remote it might re-use an existing Firefox process, effectively doing nothing. It’s likely Firefox keeps its lockfile in $HOME though so I might be overly cautious here.
            1. 2

              See Firejail, if you haven’t already. It’s a sandbox for untrusted applications.

              With it, you can put firejail --private /usr/bin/firefox "$@" in an executable in your PATH, to spawn a safer amnesiac session when needed. Firefox + firejail without the --private flag is also practically indistinguishable from without firejail.

              1. 5

                Everyone interested in firejail for “untrusted” software/security reasons should read this oss-sec thread.

                1. 1

                  Can you guide us there?

                  1. 3

                    firejail, for something that should improve security, had quite some CVEs:

                    https://www.cvedetails.com/vulnerability-list/vendor_id-16191/Firejail-Project.html

                    Some of the CVEs are easy to exploit and have a high impact.

                    1. 2

                      But that’s still better than nothing, as long as you understand it’s not perfectly ‘secure’, right? I think the problem would be that folks may not understand it has some major CVEs and expect it to be a complete solution (when it is not).

                      1. 3

                        It is really not, firefox itself already sandboxes processes, its not perfect and there a things to improve. But there are people reviewing it and looking for bugs. Firejail is a setuid binary, which already gains more privileges than firefox would ever have. Firejail introduced privilege escalation and other security issues, which lead to root by just having firejail installed and accessible to a user.

                        1. 1

                          Indeed. On the typical single-user desktop giving applications full access to the user account is just as bad as giving them root access because a root escalation does not provide significant benefits to an attacker.

                          Firejail will not block an attacker that is both skilled and motivated but at least it effectively contains a spammy or nosy application.

                          Any better solution?

                          1. 1

                            Indeed. On the typical single-user desktop giving applications full access to the user account is just as bad as giving them root access.

                            This is funny because firejail is setuid and runs as root until it drops privileges again (Some CVEs result in root for any user who can access the firejail binary). Firefox does sandboxing itself, using the same or similar techniques, but would never gain root privileges.

                            Firejail is way to complex and the design doesn’t really look like it was build with security in mind. It does way to many things in one big setuid binary. This already elevates privileges to root from a normal user, this is not how it should be designed. The perfect solution would be something that is designed with least privileges in mind and do things like dbus or xorg forwarding/proxying in a completely different low privileges process.

                            There are things like bubblewrap, but they are not as easy to use for desktop applications because they are not designed around it, you can still make with work by bind mounting the Xorg socket into the namespace or letting it connect to a separate server like Xephyr so the sandboxed application doesn’t have access to all other windows. Other things like dbus would also be handled manually.

                        2. 1

                          Yeah, anything will have vulnerabilities but what are the odds of anything targeting users on Firefox + Firejail around? And then the odds of you actually getting it?

                          1. 1

                            Looks good but my current main OS is Windows and I can’t seem to be able to find a Windows version on the repo. Is there one?

                      2. 3

                        Firejail doesn’t have the best security record, and only works on linux.

                      3. 1

                        There are better ways, as discussed here on lobsters some time ago.

                        I’ve experimented a bit lately, and here’s my notes on this topic (but there are better writings around in the Internet, of course): https://dacav.roundhousecode.com/blog/2019-05/31-sandboxed-firefox.html