LXer Feature: Browser security: why an insecure browse-only account doesn't work

Posted by hkwint on Oct 19, 2005 7:16 AM EDT
LXer; by H.Kwint; By H Kwint
Mail this story
Print this story


One of the reasons why people switch to Firefox (also on the Linux platform) is the assumed security of the browser. Nonetheless, several vulnerabilities were found in Firefox the last few months, so the browser may be the weak spot in the security of your Linux-desktop.

Trying to address this problem, I researched two ways to make browsing under Firefox more secure: chrooting it, or making a seperate browse-only account. Both of them don't work. This article discusses why, and the possible solution.

Nature of the vulnerabilities

Most desktop Linux-users who are the only user of their desktop, use two accounts: a root account for administration tasks only, and a user account for all other tasks. We will assume the user-account is called joe.

Joe has his home directory at /home/joe. In his home directory are files, probably confidential and important. These files are owned by joe.



Now, our user joe is going to use his browser, which we assume, has some exploitable vulnerabilities, which give the attacker 'current user' rights. This means, the attacker can do anything on Joe's computer, for which the user Joe has permissions. The attacker can't hurt the system itself, since he hasn't got root privileges, but the attacker could read confidential, or destroy important files in /home/joe.

How can this be prevented?


Chroot

At a first glance, it looks like a good idea to make a 'chrooted jail' for Firefox. This means, we make a 'separate file hierarchy', in which we run Firefox. This separate file hierarchy, from now one called /chroot, is separated from the normal file hierarchy in such a way, that Firefox can't see the normal file hierarchy. Making such a chrooted Firefox is not very difficult, it involves:



-making a chroot-dir in which Firefox will be copied, and from which it will run,

-copying all Firefox-bins to /chroot

-copying all libs used by Firefox to /chroot. In my configuration, this means copying 45 libs.

This will run Firefox, but there are problems:

  1. Updating



    When you're updating, your packet manager won't automatically update the chrooted Firefox. You can't link from the normal file hierarchy to the chrooted hierarchy, since the chrooted Firefox can't see the normal file hierarchy.

  2. Plugins

    This is the real problem: when browsing, Firefox may use many plugins, like for example xpdf, open office, mplayer and xmms. You also need to copy al these binaries and libraries they use to the chroot-dir.



As you see, this becomes a problem when updating, since updating involves manually doing the things under 1 and 2.

So, this solution is a bad one.


Unsafe separate browse-only account

We could also create a third account, which runs the normal Firefox-bins, and can use all the plugins, but isn't allowed to read or write to Joe's files.



Again, at a first glance this seems like a simple solution.

So I started working.

To do this, I used sudo. I created a third account, called 'browse', with 'nologin', meaning this user can't get a bash-shell.

Then, I edited sudoers to give joe the right to do anything as 'sudo -u browse' without a password. Then, I made a bash script which only runs




#!/bin/bash

sudo -u browse /usr/bin/firefox


This didn't work for two reasons:

  1. X permissions



    The used X-session was started as joe, and the browse-account didn't have the permissions to spawn windows in this session.

    The most simple way to solve the problem, is to just add

    xhost +



    to one of Joe's login scripts.

    I chose another solution, using xauth extract to extract Joe's xauth-key, and then, as browse, using xauth merge to merge the X key.

  2. Environmental variables

    When you use sudo to 'become browse', you have other environmental variables then when logging in as browse (if this wasn't disabled).



    I also had some problems with a lockfile made by firefox.

    So, I had to run sudo with env-vars:

    This script, /home/joe/bin/ffox is run as joe:



    /usr/bin/sudo -H -u browse rm /home/browse/.mozilla/firefox/71vcz8af.default/lock

    /usr/bin/sudo -H -u browse env USER=browse XAUTHORITY=/home/browse/.Xauthority MOZ_USER_DIR=/home/browse/.mozilla DISPLAY=:0.0 PROFILEPATH=71vcz8af.default /home/browse/ffox $(echo $@|cut -d ' ' -f 1-)



    This script is run as joe. It says, the lock should be removed, the USER,XAUTHORITY, MOZ_USER_DIR and PROFILEPATH vars should be changed to the ones of the browse account, and then, /home/browse/ffox should be used. Note this script also through passes arguments if given.

    So, the script /home/joe/bin/ffox runs another script, /home/browse/ffox.

    This script, /home/browse/ffox is run as browse.



    /usr/bin/firefox --display=:0.0 $(echo $@|cut -d ' ' -f 2-)



    I also copied the whole dir /home/joe/.Mozilla to /home/browse/.mozilla, and it was my intention, Firefox would only use /home/browse/.mozilla, and not Joe's dir anymore.

    All went well, till I wondered if Firefox still used the dir /home/joe/.mozilla. After deleting Joe's dir, the plugins didn't work anymore and I got some strange errors. This was surprising, since I included MOZ_USER_DIR= /home/browse/.mozilla. I searched for /home/joe in all files in .firefox, and changed all occurrences manually to /home/browse, but this still didn't enable me to delete /home/joe/.mozilla. So, annoyed, I decided

    to just keep both dirs.

    Also, the normal joe-user couldn't start firefox with plugins anymore.

    Then came the real problems, when I tried to use plugins. Updating didn't seem to work anymore. I also had a plug-in

    which allowed Firefox to control xmms. But since xmms ran as joe and Firefox as browse, this plug-in didn't work anymore. The first time I tried mplayer, it also didn't work, since the 'browse' account wasn't in the video-group.

    I also use aMSN (which is the Linux-version of Windows-Messenger), which has a feature to login in MSN, and then start your browser by clicking on a link in aMSN. This link point your browser directly to your hotmail inbox, without login in again.

    This also didn't work anymore, since aMSN ran as joe, and aMSN made a file with weblinks to the inbox owned by joe. Then I configured aMSN to use the ffox script, but this ran firefox as browse, and thus wasn't able to read the file with weblinks owned by joe. So I needed another script fixing this permission-problem.



    Also, for some reason, the auto-update function didn't work anymore, it gave errors. Probably, the plugins are still owned by joe and read from joes .mozilla dir, but the other stuff is read from the browse .mozilla dir.

    So, the problem with both the chroot and separate account are the 'plugins'.

Tired of this all, I decided I needed another solution.




Possible solutions

The solutions which came to my mind were:

-Make a secure 'separate' account, instead of an unsecured account. This account is then only used for important or confidential office documents.

-Switch to Opera

-Just switch back to the way it was and forget about Firefox-vulnerabilities




I think I'll try the third solution, since this takes the least effort.


So I hope you're warned before trying the first two solutions mentioned here, and if you have a simple solution, please let me know!


About the author (myself):



Just a hobbyist using (Gentoo) Linux for only two years, without much knowledge of old stuff. Also used *BSD, but managing that is too difficult for day-to-day desktop work.

  Nav
» Read more about: Story Type: LXer Features, News Story; Groups: Gentoo, Mozilla

« Return to the newswire homepage

Subject Topic Starter Replies Views Last Post
Interesting Idea but to hard to practice peragrin 1 2,217 Oct 19, 2005 12:42 PM

You cannot post until you login.