Launchpad Entry: security-karmic-firefox-profile
Contributors: jdstrand, asac
Packages affected: firefox-3.5, firefox
Provide a means for administrators and users to opt into AppArmor confinement in firefox.
The end-user impact for users in default installations will be non-existent. The firefox package will ship in complain-mode during the development cycle and before release (or at some point in the cycle) be updated to be disabled. Users must opt-in to using the profile and therefore should know that AppArmor confinement could cause firefox to behave unexpectedly.
Firefox is one of the most popular desktop applications in Ubuntu and is very popular outside of Ubuntu. It is an attractive target for security research and exploitation, having 58 CVEs patched in last 6 months.
Read-write access to $HOME/.mozilla and explicit deny rules for sensitive files in $HOME, such as $HOME/.ssh. Plugins in Ubuntu should work by default (possibly excepting gnupg). Have commented sections in the profile to allow people to selectively enable certain plugins and addons. but provide a somewhat lenient policy to execute applications in /usr/bin.
Binary currently uses version number as part of the path which makes upgrades tricky (eg, /usr/lib/firefox-3.5.1/firefox is confined, then upgrade to /usr/lib/firefox-3.5.2/firefox). To address this:
- path to binary in the profile should use globbing. Eg:
- ship profile as a separate conffile
- handle profile reloading carefully by performing just an "add/replace" on the profile so the old version is not detached from running firefox processes
The following tests should be performed:
- on install, the profile is disabled if the profile doesn't already exist
- on upgrade from earlier than the version of firefox providing the profile, the profile is disabled if the profile doesn't already exist
- if profile exists and is different than the shipped profile, prompt
Future work includes, but is not limited to:
abstract out some items in AppArmor abstractions
- updating the profile to handle non-Gnome environments, especially KDE and XFCE
- enabling the profile by default
Enabling the profile by default
Along with the kernel, Firefox (as a popular browser) is one of the most interesting targets for attackers and vulnerability research and has one of the highest CVE counts of any application in Ubuntu (this is not a reflection of code quality so much as on its ubiquity and impact on users).
The profile's requirements are to protect against:
- information disclosure of sensitive files, such as ssh keys, GnuPG keys, the Gnome keyring, and common password-containing files
- arbitrary code execution, such as to setuid programs or system tools
- writing to files in the user's PATH, such as ~/bin
- a manipulated environment for helper applications. Eg, adjusting LD_PRELOAD or LD_LIBRARY_PATH and then launching a plugin or Preferred Application
The profile's intended usability requirements are to work:
- with common helper applications, such as media players, torrent applications, email programs, and document viewers
- with extensions and plugins from the archive as well as 3rd-party add-ons downloaded from anywhere
with uploading from and downloading to non-sensitive files where the user expects read/write access, such as $HOME, /media, and /mnt. This includes browsing to these locations on the local system via file:///
- as a starting point for enterprises and security-conscious individuals to use or fine-tune for their environments
The profile as implemented is general enough to meet the intended usability requirements while at the same time meets the security requirements. Please note that the profile is a general purpose profile and may not be strict enough for certain environments.
While the profile does work well for many users as is and in the default Ubuntu installation, there are several roadblocks to rolling it out to all Ubuntu users and Ubuntu derivatives (some of these were discovered after 9.10 was released):
firegpg (or any GnuPG extensions) does not work with the profile and is known to break encrypted webmail (eg GMail). Access to GnuPG keys is denied by design and is one of the security requirements of the profile. This is bug #538836.
Java plugin broke due to bug #484148 (environment is scrubbed to meet a security requirement, but this leaves Java unable to find all its required libraries). While a fix for Java is committed, other helper applications and plugins which require environment variables could break in the same way as Java (though none have been reported)
the profile breaks some usage scenarios such as web development on the local machine (eg, read/write access to /var/www or anywhere else a web application might be installed)
- the profile has not been well tested in Kubuntu, Xubuntu or other derivatives and does not currently protect sensitive files in those environments (such as KWallet)
- simple, unobtrusive notifications are needed (partially implemented in apparmor-notify package).
- a GUI tool for adjusting profiles is needed
while firefox is allowed to browse through directories on the system via file:/// URIs, firefox will provide an apache-style Indexes view of the directory. This requires firefox to perform a read operation on the files in the directory. As a result, these reads will show up as denials in the log files (this happens especially when navigating outside of $HOME), but otherwise works ok
While AppArmor is relatively easy to understand, the profile tools in Ubuntu are CLI, require root access and require a basic knowledge of AppArmor rules syntax. The GUI notifications and tools are required since firefox is a very complex GUI application with disparate use cases. In contrast, these GUI tools were not required for evince (a GUI application which ships an enforcing AppArmor profile by default) because its usage requirements are well-understood and relatively easy to confine.
Proactively protecting Ubuntu users against unknown and future vulnerabilities is why the profile was developed; however, enabling the profile by default has a high risk associated with it. The expectation for default enforcing AppArmor profiles in Ubuntu is that the profile must work for the vast majority of users in the default install, without any intervention on the part of the user. Looking at other operating systems shows that when users are faced with a security mechanism that gets in the way, they turn off the security mechanism rather than fix it. Since some usage scenarios are known to conflict with the security and intended usability requirements of the profile (see the roadblocks, above), GUI tools need to be added and carefully designed to not take away from the desktop experience. Currently, if a user encounters a bug or an intended profile behavior, the desktop user experience is poor and the user might decide to turn AppArmor off entirely, thus decreasing the overall security of the system (since several profiles are enabled in the default installation).
Due to the known limitations of the profile and the high risk associated with enabling it for all users, it is recommended that the profile not be enabled by default at this time. It is important to remember that while the profile may not be turned on by default, Ubuntu is the only major operating system to have an officially-supported MAC configuration for its browser.