Some of the details here are Dragonfly-specific (such as the “video” group) but the general principal (using a different user and sharing the Xsession) should work elsewhere.
If you really don’t want to trust the browser with direct X access, then do not scp the .Xauthority file to the account in the “go” script, and ssh into the account using the -X option to forward the X11 connection. That is, ssh -X localhost -l dfw1 -n “chrome”. This will radically slow down the browser session.
Last I checked this was only true of Chrome; I used Firefox for years over an SSH-forwarded X connection. In fact, this is what got me to finally quit using Chrome.
I’ve done something similar in the past: created diferents users and used a main account to sudo(instead of ssh)into those dedicated accounts (one for browsing, one for email, another for IM, etc). One of steps was that I allowed xhost access to any client so the other users could access my X.
Also I’ve found program that automates most of this but can’t remember the name (something jail?)
I believe you’re referring to Firejail; it uses Linux kernel namespaces and seccomp to sandbox applications. I’ve been using it for a while, mainly to sandbox web browsers, and it works like a charm.
Unfortunately it seems to have caught fire ?
Firejail local root exploit http://www.openwall.com/lists/oss-security/2017/01/04/1