First some discussion. The problem of securing browsers in general is outside the scope of this little project. What I wanted was a method of going into 'secure browsing' mode occasionally for sensitive tasks such as internet banking. At the very least this requires using a different browser session from your 'everyday' browser which is too exposed to be considered safe. The problem with the Browser Appliance is that it adds too much complexity. Having a whole new operating system that requires maintenance and patching and comes with its own set of vulnerabilities is silly. Even if it is more secure than your current OS, the security is a cumulative effect, any insecurity in the browser appliance adds to the insecurity of your host OS, it doesn't replace it.

So in the vein of keeping it simple, I wanted a separate firefox session running as a different user. Extending this principle I wanted to put firefox in a restrictive read-only chroot jail to prevent any potential malware from making persistent changes and reducing the attack vectors available to any malware. Making a separate account with its own firefox files was easy enough, but chrooting firefox was an absolute mission, I plan to go back to it one day, but for now I have a thesis to write :) Once again, while trying to keep it simple I thought it would be nice to 'test' the idea with a text browser. I needed some usability and SSL support, which settled me on elinks. Chrooting this was easy enough. I used a tutorial I had written earlier on pam_chroot, and experimented with a utility called makejail. The advantage is that the account can be accessed remotely via ssh. It took me a while to get it right (and I since updated the pam_chroot tutorial).

If you are interested in doing the same thing, the makejail script I used is available as makejail-elinks.py. It copies some core libraries across, then copies the libraries elinks professes to need when poked with ldd, next makejail runs an strace on the given command and copies any other libraries accessed across. You will need an account for the new elinks user with the shell set to elinks. Check the pam_chroot tutorial for how. After that I tweaked the elinks.conf to work securely, not try to write anything, and have the banking site as the default page, you can get it here. I also added a list of other secure sites I regularly access to the bookmarks file in ~/.elinks. You can make whatever other changes you want before making the chroot read-only. When everything is to your liking just:

chmod -R ugoa-w /home/elinks

This will make everything read only. Also make sure other permissions are set right, like elinks homedir and the passwd file. Makejail does a terrible job of setting those right.

If you followed everything in the pam_chroot tutorial (like modifying /etc/security/chroot.conf to include the userdir) then that should be it. You can now ssh in to your new elinks chroot.

Of course none of this protects against rootkits and keyloggers, so you still need to keep security tight on your host machine. Also if you ssh in from somewhere else, you need to worry about keyloggers on that machine too. In fact, given that all input will be keyboard based it may be even easier for an attacker to gather relevant details. For the really paranoid using an onscreen keyboard that you click with your mouse might help. If we assume your host machines are keylogger free. Then this provides:

• An encrypted channel to access your secure session thanks to SSH.
• A secure browser session.
• a browser with less functionality will have less potential for vulnerabilities
• a less popular browser will have less announced vulnerabilities and less attacks targeting it
• malware has less to work with in the read only chroot
• SSL encryption from your host machine to the bank (check those certificates) is useful

This is great for using internet banking from places like internet cafe's.

If you really want to earn your tin-foil wings then you need to check the chroot and make sure nobody has tampered with it. This can be done by checking no files have been added, ensuring existing files haven't been modified and virus scanning the chroot. An example script of how this can be done can be found here, it isn't user friendly, but anyone who made it this far shouldn't have trouble working it out. It basically checks a list of files, md5 sums and sha1 hashes against precomputed ones to look for changes, then uses clamscan.