Running firefox a bit more safely - HOWTO

[Matthew Dillon]

dports has been updated once but a couple of problems have cropped up.  We
are going to have to revert the x11 intel video driver due to instability
in the updated version, and it turns out that the update to firefox-40 has
not fixed at least one serious vulnerability.  So we are going to have to
return firefox to the 39-series and update to 39.0.3 which does.  These
changes will go in ASAP and we will regenerate the binary dports for
-release and for master on Wednesday.

At the moment the bulk build for -release with the previous set of changes
(plus a general major update) is still running and will finish Wednesday.
However, after it finishes we will then have to update it again with the
above changes and run an incremental bulk rebuild to fix the intel driver
and firefox.

The bulk build for master is done but it also needs to be updated again
with the above changes and also needs an incremental rebuild.  This will
also be done on Wednesday.

Until we get this additional update in, X is going to be unstable and
firefox is going to remain vulnerable.  We hope to get it all done by
Wednesday evening.  I will post another followup when it is all done.

-Matt

On Tue, Aug 11, 2015 at 10:32 AM, Matthew Dillon <
dillon at apollo.backplane.com> wrote:

>     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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20150811/c8dca28d/attachment.html>