Running firefox a bit more safely - HOWTO

[Matthew Dillon]

    As people may know a firefox hack was found in the wild that allows
    any accessible file to be read.  This hack was due to a bug in
    firefox's internal PDF viewer.  The exploit that was found in the wild
    was trying to snarf developer-related files such as .ssh configuration
    files and keys.

    We finally have a fix for it for master in dports binaries (upgrading to
    Firefox 40.0).  The release branch doesn't have this fix yet but we
    hope soon.  Firefox tends to mess with a lot of packages so a binary
    update is the best way.  We're asking for a little patience for RELEASE
    users.

    In the mean time there are a few things you can do quickly:

    (1) A quick workaround is to set the PDF reader to 'always ask' and not
	use the firefox internal reader.  This can be changed in PREFERENCES
	(accessed from the upper right side of the browser) -> Applications.

    (2) You can switch to something more secure, such as chrome.  This
	would be the chromium package in binaries.  There might be a few
	gotchas here particularly with video viewing so YMMV.

    I also suggest taking the time to more seriously secure whatever browser
    you are using, and I will outline what I have done in this regard below:

    What I have done is segregate my browser use into user accounts separate
    from my main account.  I created three accounts (one for my 'secure'
    firefox use, such as accessing bank account, one for general 'unsecure'
    browsing, including most of my social media browsing, and one for
    my chrome instance which I use for other things).

    First make sure your main account(s) are fully protected.  For example:

	chmod 700 /home/yourmainaccount

    Use vipw to create three new accounts I used UIDs 30000, 30001,
    and 30002 and called them dfw1, dfw2, and dfw3.  Set password to '*'
    (no password allowed).  /home/dfw1, /home/dfw2, /home/dfw3.

    For each one of dfw1, dfw2, and dfw3 (using dfw1 as an example), set
    it up so you can ssh into it from your main account.

	mkdir /home/dfw1
	mkdir /home/dfw1/.ssh
	cp ~yourmainaccount/.ssh/id_rsa.pub /home/dfw1/.ssh/authorized_keys
	chown -R dfw1 /home/dfw1

    Then from your main account, do a 'ssh dfw1 at localhost -n ls -la' to test
    that you've set it up and it works.  I'm assuming you are also running
    sshd on your system, and I am also assuming that you've set up the
    ssh-agent for your main account / X session so you don't need to enter
    your local ssh key unlocking password every time you use ssh.

    Now you can create scripts that run firefox and/or chrome in these
    accounts, separate from your main account.  This is what a typical
    script would look like:

	#!/bin/csh
	#
	# script for ~/bin/firefox  (assumes ~/bin is in your path)
	#
	scp ~/.Xauthority dfw1 at localhost:
	ssh dfw1 at localhost -n "setenv DISPLAY :0.0; firefox"

    You can then tie these scripts into your GUI as buttons or whatever.
    This part is left up to you.  You can have a script for each
    compartment.  I have a script for 'Sfirefox' (my 'secure' firefox),
    'Ufirefox', and 'chrome'.

    The idea is to start these insecure GUI programs from the side-account
    and not from your main account.  When started from the side-account,
    the instances will not have access to general files in your main account.

    * This isn't a perfect solution because, of course, we are giving the
      side-account full access to the X session, but it is a lot more secure
      than just running firefox in the main account.

    * Also note that these applications will be able to use X shared memory
      and thus run fairly optimally (they are NOT using an ssh tunnel nor do
      we want them to as that would be ridiculously slow).  Programs run in
      this way will not have direct access to the GPU so 3D might not be
      so hot.  But for general browsing I haven't had any trouble, and even
      with 4K video appears to work about the same as it did before.

    * You can set up the GID and group permissions to e.g. access files
      and directories in the dummy accounts from your main account without
      giving the dummy accounts access to your main account.  e.g. for
      things like the Downloads directory and so on.

    * When you do this separation, the browsers will be in separate
      instances.  Be sure to setup your browser preferences in each instance.

    * I don't recommend copying your old browser config directory from your
      main account to these dummy accounts as this will also copy existing
      cookies and passwords that you might not want the dummy account to have
      access to.  Or at least be very careful in this regard.

      You can cut and pastes individual bookmarks between firefox's with
      a simple drag and drop, and you can cut and paste bookmark folders
      by right-click-cut and right-click-paste.  You can use this to
      redistribute your bookmarks to the new browser instances.

    --

    Ultimately we will have better security compartmentalization that will
    not require separating applications into dummy accounts, but for now this
    is not a bad solution.  I feel a lot better now that I've moved my
    browser execution off my main account.

    I strongly recommend this.  The last hack was really the last straw for
    me, I will never run a browser from my main user id again :-).

    If you are worried about your ssh keys being compromised I also recommend
    going through the hassle of changing your ssh keys out and killing the
    old ones.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>