AppArmorFirefoxProfile
|
Size: 2763
Comment:
|
Size: 2390
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| Line 13: | Line 12: |
| == Release Note == | == Impact == |
| Line 23: | Line 22: |
| Provide a somewhat lenient policy to execute applications in /usr/bin, read-write access to $HOME/.mozilla and explicit deny rules for sensitive files in $HOME, such as $HOME/.ssh. Have commented sections in the profile to allow people to selectively enable certain plugins and addons. | 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. |
| Line 27: | Line 26: |
| Binary currently uses version number as part of the path which makes upgrades problematic (eg, /usr/lib/firefox-3.0.9/firefox is confined, then upgrade to /usr/lib/firefox-3.0.10/firefox). To address this: * use AppArmor aliases in an #include file which is itself a conffile (and not expected to change). This file is updated be the firefox package |
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: {{{ /usr/lib/firefox-3.5.*/firefox { }}} |
| Line 34: | Line 36: |
| It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage. | 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 * aa-enforce should load the the profile ([[https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/413153|bug #413153]] needs to be fixed for reboot |
| Line 36: | Line 42: |
| This need not be added or completed until the specification is nearing beta. == Unresolved issues == This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. == BoF agenda and discussion == Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. |
Launchpad Entry: security-karmic-firefox-profile
Created: 2009-06-02
Contributors: jdstrand, asac
Packages affected: firefox-3.5
Summary
Provide a means for administrators and users to opt into AppArmor confinement in firefox.
Impact
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.
Rationale
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.
Design
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.
Implementation
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:
/usr/lib/firefox-3.5.*/firefox {- 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
Test/Demo Plan
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
aa-enforce should load the the profile (bug #413153 needs to be fixed for reboot
SecurityTeam/Specifications/Karmic/AppArmorFirefoxProfile (last edited 2010-03-21 02:41:39 by pool-71-123-4-188)