For privacy, on a linux box are there any downsides to simply creating one or more extra accounts, and running Firefox in them for privacy ('DISPLAY=:0 firefox')?. I use this approach to set up firefox as I like it on a spare account, then copy '.mozilla' to '.mozilla-base'. Then it's just a simple case of 'su -l guest' and (via a script) 'rm -fr ~/.mozilla; cp -a ~/.mozilla_base .mozilla; DISPLAY=:0 firefox; rm -fr ~/.mozilla' (actually the script deletes the local cache as well).
Net effect is that firefox starts exactly as I like, but forgets everything that happened in the session ('groundhog-day mode').
Edit: added 'su -l' step.
Edit: As an adendum, note that this technique can be extended to the complete 'guest' accounts as well, e.g. 'cd /home; rm -fr guest; cp -a guest.base guest; su -l guest'; the entire 'guest' account is then 'groundhog-dayed'.
#!/bin/sh
#
export DISPLAY=:0
# Set up clean copy
cd ~
rm -fr .mozilla
cp -a .mozilla_base .mozilla
cd - > /dev/null
#
/usr/local/bin/firefox $@
#
echo "Holding...."
sleep 2
echo "Cleaning...."
# Clean out junk (so we start clean next time)
cd ~
rm -fr .mozilla .cache/mozilla*
rm -fr .adobe
rm -fr .macromedia
cd - > /dev/null
Interesting, thanks; I haven't seen it, looks interesting and a worthy project. I tend to prefer simple low-tech solutions though, and given the first two commands to start it are to do with fixing pulseaudio bugs and desktop integration is (for me personally) somewhat of a put-off.
There's also bubblewrap, which I haven't used, but promises to be an even lighter way to sandbox applications.
Generally, I agree with you that the lighter the implementation is, the better, but when it comes to sandboxing and other security measures, I would prefer not to roll my own.
From my brief look at firejail, how would I do the rollback? (i.e. reset everything back to exactly how it was before the run). Also n.b. I'm not rolling any security measures of my own here - it's reliant on the kernel correctly separating users.
You can use --private-home to 'import' an existing set of files (e.g. a 'clean' FF profile) into the sandbox, then any modifications made to it are discarded when FF quits.
Thanks for sharing the script! This is a more "complete" version of Firefox Multi-Account Containers. Is there any concrete advantage in doing this versus opening Firefox in a new profile? For example, do Firefox profiles share some browser download caches?
I'm not familiar with Firefox Multi-account containers; do they use separate Unix accounts? (since my approach means Firefox is running as a completely diffrent user, a simple firefox compromise or bug shouldn't be able to access anything sensitive on the main account - like SSH keys, say).
They're not containers as in Linux containers, they're "contextual identities" within the same Firefox process, that isolate things like cookies. Much weaker isolation (technologically) than process/user privilege separation, but OTOH highly usable. (Well, there's the e10s process separation, but nothing anything extra for multi-account containers, as far as I understand).
I don't think they offer much in the way of security, but they do let you isolate the websites you choose from each other. I wrote a very small blog post about them: http://iamqasimk.com/2017/11/21/firefox-containers/
Indeed, that's the approach I use to run multiple copies of Thunderbird. Using a separate account does add protection against browser exploits though (if visiting an interesting-but-risky site, the 'guest' account approach prevents access to the main account - at least as long as a browser exploit doesn't then lead to a privilege escalation).
Although exploitation is more difficult, all programs that run in an X session have complete access to all the other programs in it, regardless of user ids or for that matter the host the program is running on.
As a simple demo of this, running 'gimp' as a 'guest' user allows you to take screenshots of windows owned by the user who started the session. Thus, a compromised copy of firefox on the 'guest' account could, for example, easily capture the contents of any window on the system.
Still, the main reason I run the browser as a different user is to isolate it for privacy; there are some security benefits too, but I agree it's not something that would defeat a targetted attack.
I did not know that. Turns out it’s a bit weak though, all untrusted clients have full access to all other untrusted clients. So you only have two levels. Still, better than nothing.
In both cases (on separate accounts, same computer), it said "Thank you, xx xxxx! Let's see the magic..." (I used the same user name and IP address from both).
Restarting (exactly the same version) of Firefox a second time and revisiting the site gave:
"Are you anonymous?
Do you think that switching to your browser's private browsing mode or incognito mode will make you anonymous?
Sorry to disappoint you, but you are wrong!. Everyone can track you. You can check it out for yourself. Just type your name below."
Which seems to suggest that whatever the site does failed in my (admittedly unusual but still simple) case.
However, I have little doubt that my (rather atypical) setup could be fingerprinted accurately - assuming, of course, I was part of a big enough minority to be worth advertising to.
N.B. other local factors could affect the results here; the more obvious ones are local DNS and a firewall between the ADSL router and the LAN.
Net effect is that firefox starts exactly as I like, but forgets everything that happened in the session ('groundhog-day mode').
Edit: added 'su -l' step.
Edit: As an adendum, note that this technique can be extended to the complete 'guest' accounts as well, e.g. 'cd /home; rm -fr guest; cp -a guest.base guest; su -l guest'; the entire 'guest' account is then 'groundhog-dayed'.