AppArmored FireFox

From openSUSE

AppArmored FireFox

By Alexey Eremenko “Technologov”, the open-source community member. 10.May.2007. al4321@gmail.com Updated on 24.05.2007. Document revision: v1.01

NOTE: This project is in a planning stage. It's an idea for future solution. Feel free to ask questions in the Q&A area, but only after you read this carefully.

Fore More information, please refer to the feature-request on openSUSE: https://bugzilla.novell.com/show_bug.cgi?id=255541

What is it, and how it is supposed to work ?

AppArmor itself:

AppArmor is Novell's new technology (Mandatory Access Control Mechanism) that allows some extra access rules to the local File System, beyond typical user permissions. Look at it like a Firewall, but instead of filtering IP packets, it filters accesses to the Hard Disk, and limits them.

Because AppArmor can limit access to the Hard Disk, it is very effective against zero-day attacks.

AppArmor can be used with any application, be it networked or non-networked one. Because AppArmor uses a modified kernel (Operating-System) it can only work on openSUSE Linux.

Similar, but incompatible technologies exist for other operating systems, including Windows Vista's Protected Mode and RedHat's SELinux. Windows Vista already uses Protected-mode IE7 to protect it's users from zero-day attacks.

AppArmored FireFox:

The openSUSE community (including me) trying to marry AppArmor with FireFox, the world's best Web Browser.

AppArmored FireFox is an open-source community's response to Protected Mode IE7.

Usually a browser should not access a local Hard Disk, but most of it's work is done on the web. I take this concept one level further and build an AppArmored rules for FireFox (like Firewall rules), and I tell FireFox that it is only able to read it's own executables/libraries, read-and-write to it's configuration folder (~/.mozilla) and to downloads folder (~/downloads). Additionally, I have allowed some well-known plugins to work: Java, KPDF and Flash. More plugins could be added to the rule-set over the time.

Basically, I allow FireFox access only to itself, so if a hacker hacks your FireFox browser via some kind of unknown exploit/zero-day, he still can not do much damage to your system, because he runs in a kind of sandbox. He still could steal your certificates/cookies from ~/.mozilla (or ~/.mozilla-apparmored) folder however. He won't be able to even read data from the rest of your system.

Known Limitations:

-AppArmor cannot limit access to other services running on the same system via IP.

-AppArmor cannot limit access to other programs via memory exploits.

-AppArmor limits current FireFox users to use any plugins, and disallows downloading anywhere, except ~/downloads. That is, your Desktop and $HOME are not accessible at all, not for read and not for write functions.

-AppArmor's architecture requires explicit allow rule for every new plugin there is.

This includes Java, Kget, Flash, Acrobat Reader, KPDF, etc... Most Extensions should work fine, without changes. That means, that only plugins, that I thought of, will work with AppArmored profiles. Any new plugins, that you may want to install will not work by default.

This can be fixed by opening bugreports in openSUSE bugzilla or contacting me, on a case-by-case basis.

How do I plan to convert such a limiting technology into success?

I want SUSErs (SUSE users) to be both protected and be able write to any folder and run any plugin. In other words: I don't want to hurt to the technology that *works*, and they are used to: The Standard FireFox.

All the AppArmor magic happens in the operating-system, not in FireFox, so basically a normal FireFox can be converted to AppArmored one, but this has a serious problem: there are situations where this technology limits you, the user, too much, and users want to use a standard FireFox.

For this reason I propose:

-Creating of 2 versions of FireFox: the standard FireFox (with official branding) as it is now and AppArmored FireFox, that is kind of experimental, giving extra ptotection at the expense of some limitations. The AppArmored FireFox will have strong rules.

-AppArmored FireFox should use different branding than normal FireFox, but highly preferably to be based on the official FireFox branding, so users know that this product is based on the official branding. This really means a modified Mozilla trademarks, for which we need official Mozilla permissions. (I would prefer not to end up with AppArmored IceWeasel.) I hope Mozilla is interested to counter Protected-Mode IE7, so they will allow us to make custom branding. But I don't know their politics.

With two versions, our SUSErs can continue to play with familiar thing in both settings, so they will be able to manually choose which version they want. A modified branding is needed for those users, who want to run many windows of both standard and AppArmored FireFox to distinguish between them.

So security-critical web sites should be opened with AppArmored FireFox, while if you want custom plugins or downloading anywhere on your Hard Disk, you should run your standard thing.

What Changes are needed to FireFox ?

Very little actually. (Hopefully nothing at the browser core level.)

1. Modified branding. So this can be distinguishable from standard thing. This requires some artwork and a permission from Mozilla.

A potential icon, that I voted for is this:

Image:Https://bugzilla.novell.com/attachment.cgi?id=125341

This is very important to give SUSErs a feeling that they work with an AppArmor+FireFox combo. For this reason this icon uses a modified Mozilla branding.

Speaking of Artwork we will need the mini-icon on the taskbar, the desktop icon, and the big one: about icon.

2. Separate Process (PID) for AppArmored FireFox. Process separation is very important indeed, because the current FireFox does not allow 2 versions run simultaneously.

That is, if I start the standard FireFox, I can use only it before I exit from all FireFox windows, and if I start AppArmored FireFox, I can use only that before I exit.

AFAIK: FireFox allows for several user profiles under single user to run simultaneously, but this all, is still single-process-id based. This technique does not allow for different branding or AppArmored rules, because the PID is the same. But correct me if I'm wrong. Does anybody know how-to build a FireFox with a separate PID ?

Update on 28.may.2007: it is possible to do by starting with: "firefox --no-remote -P" - we'll have to run firefox as separate profiles.

3. The setting “Always save files to” ~/downloads must be grayed and unchangeable.

4. If AppArmor is not running (either disabled, or running on non-AppArmor kernel), the program should warn user.

Update on 28.may.2007: we can start from a shell-script wrapper, which can verify if we're running in AppArmored mode, or not.

In other words, I believe that no code changes would be required, just some configuration changes.

Community help is highly appreciated in both helping me with Artwork/PID separation/AppArmored profile/RPM building, and BETA-testing at a later stage.

If we work, we have a chance to get it into openSUSE 10.3.

I have built an already working but Alpha version of AppArmored profile for FireFox.

What do I need from Mozilla and what do I give back ?

Again: This is very important to give SUSErs (SUSE users) a feeling that they work with an AppArmor+FireFox combo. For this reason this icon uses a modified Mozilla branding.

We are not allowed to distribute software with such a branding, and for this reason I would really like to have Mozilla agree for this arrangement. In turn, I would allow Mozilla “veto” vote on every decision on my part, plus ability to control the process of development of this new interesting, exciting and promising technology.

Mozilla will also get more popular because of this product, if this turns out to be a success. Also, because no source-code changes required so-far, this has an added benefit of high-stability.

Fair enough?

Q&A with a user community

Feel free to ask me questions...

Q: (by Wolfgang Rosenauer, 29.May.2007) I still don't fully understand what you mean with "PID"? What's the actual problem?

It makes no sense to me to have a completely different Firefox package.

Please list your reasons why you think that only a separate package can solve your project.

A: (by Alexey "Technologov", 29.May.2007) Read earlier. Having two FireFox'es running at once is great - mainly for experimentation with the new technology. This will allow users to work with the stable version and test the AppArmored one - at the same time. Unfortunately, due to the nature of AppArmor, there is no way to make the AppArmored FireFox to work in all cases easily - some plugins may fail, and stuff like that.

Testing a solution like that, and ironing out all the bugs in AppArmored profile is a long process, and because of this, I propose the dual-FireFox-play, starting from openSUSE 10.3 - the earlier we'll start, the earlier we'll get a stable solution.

As for the PID (Process Identifier), it's the technical part of the problem.

Once firefox (normal) is started, I can't start firefox-apparmored, because it "sees" an already running FireFox around, and starts a new window with an old PID, instead of creating a new confined process. A user sees new window, but it's not running a new process.

My recommendation: crash your FireFox to see if you have a single shared process or a different proceses.

To crash your FFox, see here: https://bugzilla.mozilla.org/show_bug.cgi?id=339954 Usually, all FireFox windows crash, when one is crashing. Again, I want to make it look-n-feel (and experience) like two separate products on the same machine.

Basically, this PID problem prevents users from running two firefoxes at once. Either apparmored or normal version can run, but not both same time.

Just think about it: using your AppArmored FireFox for suspecious sites, and use your normal FireFox for the "trusted" sites. Wouldn't it be great ?

Theoretically, a single package can do it as well, *but* we will need to modify parts of that single package to make it different experience - for it to behave like two packages - for example two executables must exist - one with normal icons/artwork/about box and other with apparmored icons/artwork/about box. PID separation is still necessary however. Also a different settings directory is necessary too, like ~/mozilla and ~/mozilla-apparmored. I want to make it impossible to attack a normal ~/mozilla from the AppArmored version.

Hope this answer was full enough...

Q: (by Wolfgang Rosenauer, 29.May.2007) I see that it would be nice if there was another logo included in the about window but the price for that is too high I feel.

A: (by Alexey "Technologov", 29.May.2007) Yes, I know that the cost is high. Let's hear other opinions too - what do Mozilla think about this effort ?

The other way is going the "AppArmored IceWeasel" route - something I don't really want - but maybe we can settle an arrangement that both parties will agree on. (Novell+Mozilla+community)

By Alexey Eremenko “Technologov”, the open-source community member. al4321@gmail.com