firefox apparmor profile is too lenient

Bug #592121 reported by Hadmut Danisch
268
This bug affects 3 people
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.d/usr.bin.firefox and will that way loose security updates with new packages or turn apparmor completely if a new package comes with a different version number in the file path.

Having such config files is irresponsible. Thats ignorant and botching with security.

apparmor comes with /etc/apparmor.d/abstractions/user-download. There should also be a user-upload and firefox should
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-0ubuntu4
ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic i686
NonfreeKernelModules: wl
Architecture: i386
Date: Thu Jun 10 13:04:08 2010
EcryptfsInUse: Yes
FirefoxPackages:
 firefox 3.6.3+nobinonly-0ubuntu4
 firefox-gnome-support 3.6.3+nobinonly-0ubuntu4
 firefox-branding 3.6.3+nobinonly-0ubuntu4
 abroswer N/A
 abrowser-branding N/A
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.utf8
 SHELL=/usr/bin/tcsh
SourcePackage: firefox

Tags: apparmor
Revision history for this message
Hadmut Danisch (hadmut) wrote :
visibility: private → public
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

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/SecurityTeam/Specifications/Karmic/AppArmorFirefoxProfile

Changed in firefox (Ubuntu):
status: New → Invalid
summary: - grossly negligent apparmor settings
+ firefox apparmor profile is too lenient
tags: added: apparmor
removed: apport-bug i386 lucid
Revision history for this message
Hadmut Danisch (hadmut) wrote : Re: [Bug 592121] Re: grossly negligent apparmor settings

I definitely do not understand how somewhat with such a point of view
and such an incompetency, who does not even understand the point,
could get in charge of such security relevant functions.

Your argumentation of not wanting to protect the user against himself
completely misses the point of attacking the browser and causing it to
read and write files from the user's directory. It also a violation of
the idea of apparmor.

May I ask what qualifies you to deal with security requirements in a
Linux distribution?

Hadmut

Revision history for this message
Jamie Strandboge (jdstrand) wrote :
Download full text (3.2 KiB)

I'll put your personal attack aside and address your point as I think your main question is valid. I would appreciate it if you would discontinue these attacks.

I did not miss your point. The browser is supposed to be able to read and write files from the user's directory. This is *by design* of the browser, in particular firefox. How else is someone supposed to download a file? To upload their presentation to the company webserver? If the AppArmor profile denied these actions by default, what would the regular user who knows nothing of AppArmor do?
 * If we were lucky, they would only turn off only the firefox profile (which, I might add is *opt in* only right now). This action would weaken the security stance of firefox since it would now be running totally unconfined.
 * If we were more unlucky, the user would turn off all of AppArmor (this has been seen occasionally with AppArmor but famously with SELinux). The result would be that CUPS, dhclient, evince, the guest-session and other profiles in Ubuntu would be disabled.
 * If we were most unlucky, the user would become frustrated with Ubuntu and use another OS, likely complaining to everyone they know about it. Considering all of Ubuntu's proactive security features (including, but in no way limited to AppArmor) and depending on what OS they choose, this could greatly decrease the security stance for the user.

The browser is arguably the most important application a regular user uses. If we are cavalier about breaking the most used application on the Desktop, then from the user's point of view the Desktop and OS are broken. We must carefully weigh usability requirements against security protections in all cases, otherwise it leads to frustration and the security feature being turned off.

AppArmor can protect against many things. The firefox profile protects against execution of arbitrary code by the browser and reading/writing of files you do not own (eg /etc/passwd), reading/writing sensitive files like the user's gnome-keyring, ssh keys, gnupg keys, history files, swp, backup files, rc files and to files in the standard PATH. It also confines add-ons and extensions to the above. Firefox is integrated into the Desktop and so it must be allowed to open helper programs and access the user's data. The profile is by default *general purpose* with the design being:
 * when enabled, it significantly improves the security of firefox as is
 * it provides a starting point for people to confine firefox how they want to
 * the implementation gives the user the ability to fine-tune it to be as strict as desired

Of course firefox can be locked down more to protect the user's data. We could make it so that it could only write to ~/Downloads and read from ~/Public. However, this deviates from upstream's design, would likely put Ubuntu's Mozilla branding at stake, and most importantly frustrate users. Is Ubuntu's profile a "violation of the idea of apparmor"? Of course not -- it *is* protecting user's from various attacks and many forms of information disclosure. It is a distribution requirement to provide a functional browser. It is a distribution choice to not break it with too-aggressive securit...

Read more...

Changed in firefox (Ubuntu):
status: Invalid → Won't Fix
Revision history for this message
Hadmut Danisch (hadmut) wrote : Re: [Bug 592121] Re: firefox apparmor profile is too lenient
Download full text (8.2 KiB)

On 10.06.2010 17:40, Jamie Strandboge wrote:
> I'll put your personal attack aside

Unfortunately, it is a major american attitude and a trained form of
ignorance to void and discard a complete class of critics. When making
a mistake which's reasons are in the personal views and mind of the one
who makes the mistake, critics are necessarily personal. Ignoring these
forms of critics, as it is common an usual in the american culture,
opens the door for a full category of flaws, mistakes, and wrong
decisions, which are on one hand as well part of the US culture, but on
the other hand absolutely inacceptable in concerns of security.

> and address your point as I think
> your main question is valid. I would appreciate it if you would
> discontinue these attacks.
>

And I would appreciate if you'd fix the problem and listen to my bug
report.

The way you were ignoring my points and marking them as invalid was
highly offensive seen from my personal cultural background. American
people tend to accept only the american way of life as the only valid
form of interaction. There is no non-personal way of dealing with
someone not willing to listen to non-personal arguments.

> The browser is supposed to be able to read and write files from the user's directory.

Technically wrong.

The browser is supposed to read and write just it's configuration
files/directory.

Besides that, the browser is supposed to read and write files from a
user's directory if and only if the user explictely wants to do so, and
only those files the user wants to read or write. The browser is
definitely not supposed to read and write any file in $HOME or /* . I
don't see where you would take that definition from.

Especially, the browser is not supposed to read or write files silently
without user's consent. But that's exactly what happens if under attack.

> This is *by design* of the browser, in particular firefox.

Wrong claim for two reasons.

The first is: There is no such design and no such task of the browser.
Show me where that design should be defined.

The second is: You simply do not understand what security is and means.
Even if that was a design of the browser, your argument was wrong.
Because there are attacks and flaws in the browser, and therefore the
browser accidently or because of attack does something it is not
designed to do.

Or in other, more simple words: Let the browser do what it is designed
for, but use security to prevent it from things it was not designed to.

For example, the browser is designed to open a requester and to
inform/ask the user before up-/downloading a file. Silently reading or
writing arbitrary files without user's consent is definitely against
firefox' design, so your point is technically wrong.

(and btw, even if you take this as a personal attack, but it's something
that must be said, because that's the main problem: Someone who argues
the way you do is definitely not competent in IT security. Maybe it
would be better to pass the security relevant tasks in ubuntu to someone
else experienced with such problems.)

> How else is someone supposed to download a file? To upload their presentation to the company webserver? ...

Read more...

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :
Download full text (10.0 KiB)

@Hadmut Danisch:

Please review the Ubuntu Code of Conduct, and cease the personal attacks
immediately:

http://www.ubuntu.com/community/conduct

> > The browser is supposed to be able to read and write files from the user's directory.
>
> Technically wrong.
>
> The browser is supposed to read and write just it's configuration
> files/directory.
>
> Besides that, the browser is supposed to read and write files from a
> user's directory if and only if the user explictely wants to do so, and
> only those files the user wants to read or write. The browser is
> definitely not supposed to read and write any file in $HOME or /* . I
> don't see where you would take that definition from.
>
> Especially, the browser is not supposed to read or write files silently
> without user's consent. But that's exactly what happens if under attack.

There is no way to differentiate, in an apparmor profile, which files
the user intended to open, and which files were opened while under
attack in the user's home directory. For users who know in advance which
files they will open, the apparmor profile can be customized.

> > This is *by design* of the browser, in particular firefox.
>
> Wrong claim for two reasons.
>
> The first is: There is no such design and no such task of the browser.
> Show me where that design should be defined.

Simply visiting a website to upload a picture to an online album clearly
illustrates the browser was meant to open files specified by the user.

> The second is: You simply do not understand what security is and means.
> Even if that was a design of the browser, your argument was wrong.
> Because there are attacks and flaws in the browser, and therefore the
> browser accidently or because of attack does something it is not
> designed to do.
>
> Or in other, more simple words: Let the browser do what it is designed
> for, but use security to prevent it from things it was not designed to.

Reading files from the user's home directory is something the browser
was designed to do.

>
> For example, the browser is designed to open a requester and to
> inform/ask the user before up-/downloading a file. Silently reading or
> writing arbitrary files without user's consent is definitely against
> firefox' design, so your point is technically wrong.

This is not something that can be enforced with MAC. You should look
elsewhere than Apparmor or SELinux for this type of protection.

> (and btw, even if you take this as a personal attack, but it's something
> that must be said, because that's the main problem: Someone who argues
> the way you do is definitely not competent in IT security. Maybe it
> would be better to pass the security relevant tasks in ubuntu to someone
> else experienced with such problems.)

Please refrain from personal attacks.

> > How else is someone supposed to download a file? To upload their presentation to the company webserver? If the AppArmor profile denied these actions by default, what would the regular user who knows nothing of AppArmor do?
> >
>
> Sorry, but that point is both silly and wrong. I would appreciate if
> you'd remain objective, because in my cultural background it is
> considered as rud...

Revision history for this message
Jamie Strandboge (jdstrand) wrote :
Download full text (13.8 KiB)

Rather than discussing the issue, you also speak of me being an American and all the ignorance that that brings, my qualifications for working in security, and accuse me of ignoring your arguments. I did not reciprocate, but instead, attempted to answer the points at hand. You also quoted me out of context: "I'll put your personal attack aside". I actually said "I'll put your personal attack aside and address your point as I think your main question is valid." I am not ignoring your point regarding *this bug*, I am choosing not to engage you in your attacks.

After responding to your report, I later marked the bug as "Won't Fix" as opposed to "Invalid" as I recognize that your point is not invalid. In other words, I was open to your criticism of the profile and recognized my mistake at marking it invalid. For whatever reason, we seem to not be communicating effectively, which is a shame. However, I will one more time try to address your points in order:

> > The browser is supposed to be able to read and write files from the user's directory.
> Technically wrong.
> The browser is supposed to read and write just it's configuration files/directory.

This URL is counter to your argument: files:///home/<username>. Web browsers have long been able to be used as a file browser so that people can navigate to the files they need access to for uploads or editing (consider add-ons for web development).

> Besides that, the browser is supposed to read and write files from a
> user's directory if and only if the user explictely wants to do so, and
> only those files the user wants to read or write.
I agree with that, but a security protection such as DAC or a MAC system cannot know what files a user wants to have access to. It must be *configured*. DAC in Ubuntu is configured with 755 home directories (for historical reasons and which may change in a future version) with read/write access to $HOME. Since Ubuntu does not want to break a user's browser, the profile by default allows a user access to her files. AppArmor doesn't know if it is a user accessing the files, or the process due to an exploit. We can only confine the process, so unless we want to drastically impact usability, we cannot *by default* have a too strict profile (see below for more on this).

It is recognized that the profile does not meet the needs of everyone, which is why the profile is a configuration file that people can edit however they wish. You are forgetting that shipped files in /etc are not overwritten on upgrades. To the contrary, dpkg is very careful about changes made to files in /etc and will prompt the user for when there are changes. It is recognized that there are usability problems with this (see below).

> The browser is definitely not supposed to read and write any file in $HOME or /* . I
> don't see where you would take that definition from.
Again, the "file://" URL is one such indication. So is the Open file dialog and the Save As dialog. All (and likely many more) are indications that the browser is supposed to be able to read and write files. With regard to the browser, DAC in general enforces writing only to $HOME. Browsers that run on Unix understand what it...

Revision history for this message
bereshit (vendetta7) wrote :

hi

I also think that the default profile is too loose,

but apart want not to deviate from the basic security policies mozilla

what are real problems that would cause a limitation of Firefox folders

. Firefox
public
Downloads

?

what are the cases in which a restriction like this (which I think are the folders that you simply use firefox) create problems?

ps: sorry for my english

Revision history for this message
Hadmut Danisch (hadmut) wrote :

Here you have plenty of reasons why the current state of the ubuntu firefox/thunderbird apparmor configuration is a security nightmare:

http://www.mozilla.org/security/known-vulnerabilities/firefox36.html#firefox3.6.7

Changed in firefox (Ubuntu):
status: Won't Fix → Fix Committed
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I have changed this to Fix Committed since at least part of the issue in this bug is that the shipped profile is a conffile which makes restricting the profile more difficult than it needs to be.

With the next firefox in Ubuntu 10.10, this easier to configure. Specifically, a stripped down /etc/apparmor.d/usr.bin.firefox profile is shipped by firefox and it will include /etc/apparmor.d/local/usr.bin.firefox and /etc/apparmor.d/abstractions/ubuntu-browsers.d/firefox. The latter will ship by default with the abstractions in /etc/apparmor.d/abstractions/ubuntu-browsers.d/* enabled, but this can be controlled with the aa-update-browser command or hand edited to remove what is not wanted (for now, this won't be touched on upgrades, see debconf note below). The former can be adjusted as desired and will never be touched on upgrades.

The profile is still disabled by default. Setting the firefox profile's mode (ie enabled vs disabled) and configuring /etc/apparmor.d/abstractions/ubuntu-browsers.d/firefox via debconf is planned, but may not land this cycle.

Revision history for this message
Hadmut Danisch (hadmut) wrote :

Thank you

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox - 3.6.8+build1+nobinonly-0ubuntu3

---------------
firefox (3.6.8+build1+nobinonly-0ubuntu3) maverick; urgency=low

  [ Chris Coulson <email address hidden> ]
  * Fix LP: #605336 - "Report Broken Web Site" option missing - don't
    disable the reporter extension when building with DEB_MIN_SYSDEPS=1
    - update debian/rules
  * Add DEB_HOST_GNU_CPU to MOZ_SYMBOLS_EXTRA_BUILDID to avoid the
    possibility of filename collisions on the server if our builds
    happen to run at the same time
    - update debian/rules
  * Build without MOZILLA_OFFICIAL=1 for beta until LP #623509 is fixed,
    so we're not sending empty crash reports
    - update debian/rules

  [ Jamie Strandboge <email address hidden> ]
  * add debian/usr.bin.firefox.apparmor.10.10 (LP: #565756, LP: #592121)
  * debian/rules: updated for usr.bin.firefox.apparmor.10.10
  * debian/firefox.postinst.in:
    - remove old code for the dailies
    - update for local include file
    - update for addons include file
    - use '-T -W' with apparmor_parser to pull in abstraction updates
  * debian/firefox.postrm.in:
    - update for local include file
    - update for addons include file

  [ Micah Gersten <email address hidden> ]
  * fix LP: #559154 - KDE users installing Firefox from archive don't know
    about kmozillahelper; kmozillahelper was renamed to firefox-kde-support
    so update Suggests
    - update debian/control
 -- Chris Coulson <email address hidden> Thu, 26 Aug 2010 00:09:49 +0100

Changed in firefox (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.