firefox apparmor profile is too lenient
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
firefox (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: firefox
Hi,
there's currently a flash/pdf exploit increasingly floating around.
Checking the apparmor config file that comes with firefox, I found that it is still grossly negligent. Have a look at this:
# so browsing directories works
/ r,
/**/ r,
# allow read and write to all user's files, except explicitly denied ones
@{HOME}/ r,
@{HOME}/** r,
owner @{HOME}/** w,
owner @{HOME}/Desktop/** r,
# removable media and filesystems
/media/** r,
/mnt/** r,
/srv/** r,
owner /media/** w,
owner /mnt/** w,
owner /srv/** w,
doesn't that mean that firefox can virtually write to everything a user with standard file permissions can write anyway?
What's the point in having such apparmor files? Using apparmor while completely disabling it at the same time? (In german we call this taking a shower without getting wet).
If at least that part of the config would have been put into an abstraction, then the local admin could permanently modify this to meet local needs. But this way the admin needs to modify /etc/apparmor.
Having such config files is irresponsible. Thats ignorant and botching with security.
apparmor comes with /etc/apparmor.
use only these files to leave it to the local administrator to choose what should be available.
regards
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: firefox 3.6.3+nobinonly
ProcVersionSign
Uname: Linux 2.6.32-22-generic i686
NonfreeKernelMo
Architecture: i386
Date: Thu Jun 10 13:04:08 2010
EcryptfsInUse: Yes
FirefoxPackages:
firefox 3.6.3+nobinonly
firefox-
firefox-branding 3.6.3+nobinonly
abroswer N/A
abrowser-branding N/A
ProcEnviron:
PATH=(custom, no user)
LANG=en_US.utf8
SHELL=
SourcePackage: firefox
visibility: | private → public |
Changed in firefox (Ubuntu): | |
status: | Invalid → Won't Fix |
Changed in firefox (Ubuntu): | |
status: | Won't Fix → Fix Committed |
Thank you for using Ubuntu and reporting a bug.
First off, in a standard Ubuntu install, PDFs are handled by evince, which is covered by an AppArmor profile and if the firefox profile is enabled it will run evince confined.
Second, if the firefox profile is enabled and is configured to use nspluginwrapper, when flash content is processed, firefox transitions to unconfined. Depending on the vulnerability, it may or may not be confined by the profile. If the user installs acroread and configures firefox to use it instead of evince, the same thing will happen if there is a vulnerability in acroread. As an aside, this is generally not the case for addons and extensions since they execute within the firefox context rather than a separate exec.
Keep in mind a couple of things:
1. The goal of the firefox apparmor profile is not to protect the user from herself, but instead to add a layer of protection against *firefox* executing code and launching other attacks. Due to a number of factors, not least of which usability and development time, the firefox profile will run many helper applications unconfined.
2. Users expect to be able to download and upload files, as well as access those files on removable media. Also, these lines apply to directories only:
/ r,
/**/ r,
3. The profile explicitly denies read/write access to sensitive files via the priate abstraction and write access to ~/bin (which is in the user's PATH).
All of these things combined does improve the security stance of firefox, by effectively making it run within a sandbox. That said, it is recognized that security minded people and enterprise users will want to make the profile less general purpose and further restrict firefox, which is why the profile is shipped in /etc as a configuration file. It is planned that Ubuntu 10.10 will make it easier to fine browser profiles.
For more information on the design of the profile, please see https:/ /wiki.ubuntu. com/SecurityTea m/Specification s/Karmic/ AppArmorFirefox Profile