LXer Feature: Browser security: why an insecure browse-only account doesn't work
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?
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:
-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:
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
sudo -u browse /usr/bin/firefox
This didn't work for two reasons:
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
Also, the normal joe-user couldn't start firefox with plugins anymore.
came the real problems, when I tried to use plugins. Updating didn't
seem to work anymore. I also had a plug-in
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.
So, the problem with both the chroot and separate account are the 'plugins'.
Tired of this all, I decided I needed another solution.
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.
|Subject||Topic Starter||Replies||Views||Last Post|
|Interesting Idea but to hard to practice||peragrin||1||1,140||Oct 19, 2005 11:42 AM|
You cannot post until you login.