docs/docs/handbook/RunSecureBrowser/index.mdwn

   1 # How to Run a More Secure Browser
   2
   3 Of all the applications you might install, the browser is probably the most useful, and also the most exposed to third-party exploits.  Here are simple modestly complex (easy if you are familiar with BSD/Linux) instructions on how to make your browser a bit more secure.
   4
   5 We at DragonFlyBSD recommend that you run your browser under a different account than your main account.  You can do this by creating one or more additional user accounts (I use `dfw1`, `dfw2`, and `dfw3`) whos sole purpose is to run the browser.  Lets take **`dfw1`** for example.  You would create the account, setup .ssh/authorized_keys in it to accept an ssh from your main account, and place the new account in the `video` group in `/etc/groups` to allow it to access GPU acceleration features.  In addition, when you login to your main account you will want to copy your `.Xauthority` file to the additional user account(s).  Once all of this is done properly you can run the browser from your main account with something like the following, and you can also program the script as buttons in your favorite window manager or desktop environment to make it easy:
   6
   7     ssh localhost -l dfw1 -n "setenv DISPLAY :0.0; chrome --site-per-process"
   8
   9 Note that in addition to creating separate account(s), we also recommend you use the experimental `--site-per-process` option when starting Chrome/Chromium.  This further isolates Chrome/Chromium tabs into separate processes which helps mitigate [Spectre](https://spectreattack.com/) JavaScript attacks.  Multiple layers of security and distrust of everything is just about the only way.
  10
  11 ## Steps to create the user account
  12
  13 1. Use `adduser` to create the account.
  14
  15     <pre>
  16     root# adduser -G video
  17     Username: dfw1
  18     Full name: Dummy User1
  19     Uid (Leave empty for default):
  20     Login group [dfw1]:
  21     Login group is dfw1. Invite dfw1 into other groups? [video]:
  22     Login class [default]:
  23     Shell (sh csh tcsh zsh rzsh git-shell nologin) [sh]:
  24     Home directory [/home/dfw1]:
  25     Home directory permissions (Leave empty for default): 750
  26     Use password-based authentication? [yes]: no
  27     Lock out the account after creation? [no]:
  28     Username   : dfw1
  29     Password   : <disabled>
  30     Full Name  : Dummy User1
  31     Uid        : 1006
  32     Class      :
  33     Groups     : dfw1 video
  34     Home       : /home/dfw1
  35     Home Mode  : 750
  36     Shell      : /bin/sh
  37     Locked     : no
  38     OK? (yes/no): yes
  39     adduser: INFO: Successfully added (dfw1) to the user database.
  40     Add another user? (yes/no): no
  41     Goodbye!
  42     root#
  43     </pre>
  44
  45 2. Give your main account access to the `dfw1` group, allowing you to access downloads and such from your main account.
  46
  47     <pre>
  48     root# pw groupmod dfw1 -m mymainuser
  49     </pre>
  50
  51 3. Make the account SSH-accessible from your main account.
  52
  53     <pre>
  54     root# mkdir -m 700 ~dfw1/.ssh
  55     root# cp ~mymainuser/.ssh/id_rsa.pub ~dfw1/.ssh/authorized_keys
  56     root# chown -R dfw1 ~dfw1/.ssh
  57     </pre>
  58
  59 4. Create a `go` script that you would normally run once after starting X and logging into your main account.  I usually create this script in `~/bin`.  Run the script to make sure it works and to install the initial `.Xauthority` file.
  60
  61     <pre>
  62     mymainuser% mkdir ~/bin
  63     mymainuser% cat > ~/bin/go << _EOF_
  64     &#35;!/bin/csh
  65     &#35;
  66     &#35; Prepare SSH and X11 forwarding to run a more secure browser
  67     &#35;
  68     ssh-add
  69     scp ~/.Xauthority dfw1@localhost:~
  70     _EOF_
  71
  72     mymainuser% chmod a+x ~/bin/go
  73     mymainuser% rehash  # if running csh or tcsh
  74     mymainuser% go
  75     </pre>
  76
  77 5. Then from your main user account, from an xterm, test it out:
  78
  79     <pre>
  80     mymainuser% ssh localhost -l dfw1 -n "DISPLAY=:0.0 notty chrome --site-per-process"
  81     </pre>
  82
  83 6. Do any other browser setup you wish to do.  You can cut and paste bookmarks and bookmark folders from wherever your browser was originally running.
  84
  85 ## Additional Security for the Machine
  86
  87 1. Secure your main account, typically with `chmod 750 ~mymainuser`.
  88
  89 2. Secure any other directories or mount points that you do not wish the ~dfw1 user to access by making sure world permissions are turned off on those directories.  Double check and make sure that the dfw1 user cannot access the stuff you don't want it to access by `su`'ing into it (`su - dfw1`) and attempting to access said stuff.  Make sure the dfw1 user account is not using a primary group that is shared with other accounts.
  90
  91 3. You can create multiple accounts (e.g., `dfw1`, `dfw2`, `dfw3`) to isolate browser instances from each other.  For example, you can use `dfw1` for general browsing and use `dfw2` for secure accounts that you trust (such as your GMail account).  It is very important that each of these accounts be isolated from the others, so do not share the same primary group.  *Be doubly sure that these isolation accounts are not in the `wheel` group*.
  92
  93 4. These accounts must have access to the `video` group in order to be able to access video acceleration.  Never make this group the account's primary group.  Add the account name to the video group in `/etc/group` instead.  This is a security issue in of itself.  *If you really don't want to trust the browser to access acceleration then don't give the account access to the group*.  However, browsing and video will run more slowly.
  94
  95 5. The X server is also a security weak point.  By `scp`'ing your `.Xauthority` file you are giving these accounts direct access to the X server.  *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 --site-per-process"`.  This will radically slow down the browser session.
  96
  97 * Be sure not to copy `.Xauthority` to the target account that you don't trust with direct access to X.  Remove any stale `.Xauthority` file that might be present from earlier testing.
  98
  99 * Also remove the target account from the `video` group if you don't want to trust it with accelerated X.
 100
 101 6. I usually create three dummy accounts for isolation.  I use `dfw1` for general browsing, `dfw2` for secure browsing, and `dfw3` for dangerous browsing.  I copy the `.Xauthority` file (remember it must be copied each time you start X on your workstation) to `dfw1` and `dfw2`, but *not* to dfw3.  And only `dfw1` and `dfw2` are given access to the `video` group, while I use `ssh -X` for `dfw3`.
 102
 103 7. Some X programs may not be happy with limited access to the X server, so YMMV in terms of using `ssh -X` or removing the account from the video group.
 104
 105 ## Additional security for the isolation accounts
 106
 107 * Each account is its own isolated instance, so bookmarks will not be shared.  Nor do you want to share them.  To prevent accidental cross-contamination, be sure that your bookmark tabs in each instance is limited to only the sites you wish to access from said instance.  For example, I have a 'Google' bookmark in my `dfw1` browser but I only have a bookmark direct to GMail in my `dfw2` browser.  I don't want to accidentally do generic Google searches from my secure `dfw2` instance!
 108
 109     *I can't repeat enough how important it is to isolate your email and bank and other extremely sensitive accounts into their own secure instance and using that instance ONLY to access those accounts.*
 110
 111 * Once you've setup the directory structures, you can make most of the main directories in the isolation account that the browser does not need to write to owned by your main account, or by `root`.  This will help reduce the damage a compromise can do.
 112
 113 * Don't just trust the stuff in an isolation account.  For example, if you need to modify the `.ssh` directory, then `ssh` (or `su`) into the isolation account itself and manipulate it as the isolation account owner and not as `root`, so fake soft-links don't do any damage.
 114
 115 * In the steps outlined above the isolation account has a **disabled password** (i.e. `*`).  In fact, DragonFlyBSD by default allows no plaintext passworded logins via SSH which allows you to set a password on your main account for logging into X (say, if you use `xdm`), but ensures that it cannot be used to login to your workstation from the outside.  We recommend that you never open any account up to outside password access.
 116
 117 * Your main account's `.ssh/id_rsa*` files should be *password-protected* if not already.  The `ssh-add` command I put at the beginning of the `~/bin/go` script is meant for you to gain access to your own keys before using in within your X session.
 118
 119 * If you suspect a breech, the first thing to do is to disconnect your workstation from the internet, then use `killall` to STOP (not kill) any processes running as `dfw1`, `dfw2`, and `dfw3`.  Then STOP any processes that look suspect.  Then dive your system and examine stuff more closely until your are satisfied.
 120
 121 ## The `--site-per-process` option to chrome
 122
 123 We now recommend this option to help defend against Spectre JavaScript attacks.  This option segregates each site in the tabs you have open into its own user process.  This is in addition to using account separation to completely isolate important sites from general browsing and social media.
 124
 125 ## Convenience vs Security
 126
 127 If I wanted to be ultra-secure I'd only run a browser from an isolated physical machine that isn't my workstation.  But convenience is a big issue, and honestly speaking most people want to run their browser on their main workstation.  The suggestions above will reduce, but not eliminate, the risk.