AppArmor profile for firefox
This is to discuss what is needed to build, test and deploy the AppArmor profiles needed to confine firefox sanely.
Blueprint information
- Status:
- Complete
- Approver:
- Rick Clark
- Priority:
- Undefined
- Drafter:
- Jamie Strandboge
- Direction:
- Needs approval
- Assignee:
- Jamie Strandboge
- Definition:
- Approved
- Series goal:
- Proposed for karmic
- Implementation:
-
Implemented
- Milestone target:
-
karmic-alpha-6
- Started by
- Jamie Strandboge
- Completed by
- Jamie Strandboge
Related branches
Related bugs
| Bug #375422: apparmor fails to load at startup | Fix Released |
| Bug #382917: ship opt-in enforcing apparmor profile for firefox | Fix Released |
Whiteboard
* Introduction
* Very popular
* Attractive target for security research and exploitation
* Apparmor confinement
* firefox proper
* extensions, add-ons, etc
* Target audience
* default mode
* could add notifications for confinement rejections, possibly via D-Bus
* gui? directly in firefox?
* policy considerations (lenient, strict, choice of one or the other?)
* potential levels of confinement:
* warnings-only
* blacklist file access, run only out of /usr, ~/.mozilla
* local profiles
* can switch to a gpg profile within the firefox profile without needing to confine gpg in general
* devel vs release modes
* during devel leave complain mode on, then make decision about how to handle it for release
* Packaging
* binary currently uses version number as part of the path which tends to make dealing with plugins and helper applications
* options for how to ship the profile:
* drop version elements in firefox path
* profile alias file is updated by firefox, and referenced from the core profile
* nervous about configuration files and upgrade prompts
* potentially low-risk to ship a profile conf-file (very few people will edit it)
* ship alias file as config-file, and split firefox profile itself into another profile
* handle profile reloading more carefully
* instead of doing an apparmor reload, perform just an "add" on the new profile so the old version is not detached from running firefox processes
* Plugin/
* sitting in .mozilla/
* helper confinement transitions (may need to implement "switch to profile if it exists" profile mode)
* generic helper launching could be limited to /usr and /usr/bin ("unconfined unless profile exists" -- see above)
* possibly track helpers via audit rules
* Misc
* general rule to audit all unexpected shadow or passwd read/writes
* Earlier attempts at firefox confinement didn't have as many AA features to leverage
* May be helpful to split apparmor syslog output to a separate /var/log output file (requires something better than sysklog)
