DragonFly BSD

RunSecureBrowser

How to Run a More Secure Browser.

Of all the apps 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.

We at DragonFlyBSD recommend that you run your browser under a different account id 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 scp 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 GUI to make it easy:

ssh localhost -l dfw1 -n "setenv DISPLAY :0.0; chrome"

Steps to create the user account

  1. Use adduser to create the account.

    root# adduser -G video 
    Username: dfw1
    Full name: Dummy User1
    Uid (Leave empty for default): 
    Login group [dfw1]: 
    Login group is dfw1. Invite dfw1 into other groups? [video]: 
    Login class [default]: 
    Shell (sh csh tcsh zsh rzsh git-shell nologin) [sh]: 
    Home directory [/home/dfw1]: 
    Home directory permissions (Leave empty for default): 750
    Use password-based authentication? [yes]: no
    Lock out the account after creation? [no]: 
    Username   : dfw1
    Password   : 
    Full Name  : Dummy User1
    Uid        : 1006
    Class      : 
    Groups     : dfw1 video
    Home       : /home/dfw1
    Home Mode  : 750
    Shell      : /bin/sh
    Locked     : no
    OK? (yes/no): yes
    adduser: INFO: Successfully added (dfw1) to the user database.
    Add another user? (yes/no): no
    Goodbye!
    root# 
    
  2. Make the account ssh-accessible from your main account.

    mkdir /home/dfw1/.ssh
    cp ~mymainuser/.ssh/id_rsa.pub /home/dfw1/.ssh/authorized_keys
    chown -R dfw1 /home/dfw1/.ssh
    
  3. 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 (ignore the backslashes, I can't seem to escape the '#'). Run the script to make sure it works and to install the initial .Xauthority file.

    mymainuser% mkdir -p ~/bin
    mymainuser% vi ~/bin/go
    
    \#!/bin/csh
    \#
    \# ~/bin/go script file
    ssh-add
    scp .Xauthority dfw1@localhost:
    
    mymainuser% chmod 755 ~/bin/go
    mymainuser% rehash  (if running csh or tcsh)
    mymainuser% go
    
  4. Give your main account access to the dfw1 group, allowing you to access downloads and such from your main account. Do this by adding your main account to the "dfw1" group in "/etc/group".

  5. Then from your main user account, from an xterm, test it out:

    mymainuser% ssh localhost -l dfw1 -n "DISPLAY=:0.0 notty chrome"
    
  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.

Additional Security for the Machine

  1. Secure your main account, typically with 'chmod 750 ~mymainuser'.

  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.

  3. You can create multiple accounts to isolate browser instances from each other. i.e. dfw1, dfw2, dfw3. 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.

  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.

  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". This will radically slow down the browser session.

    • 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.

    • Also remove the target account from the 'video' group if you don't want to trust it with accelerated X.

  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. Only dfw1 and dfw2 are given access to the 'video' group. I use ssh -X for dfw3.

  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.

Additional security for the isolation accounts.

Convenience vs Security

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.