firefox apparmor profile blocks access to /usr/local/lib

I think the behaviour you are describing is the correct behaviour; since firefox shouldn't normally be reading libraries from /usr/local/lib it shouldn't have permissions in apparmor to let it read it.

Dave

Dave Gilbert wrote:
> I think the behaviour you are describing is the correct behaviour; since
> firefox shouldn't normally be reading libraries from /usr/local/lib it
> shouldn't have permissions in apparmor to let it read it.
>
Why would that be? If you have libraries in /usr/local/lib, you have
them there to be used. You have to go out of you way to get ld.so to
look there. What possible rationale could you come up with to say that
firefox shouldn't have access to one of the normal places to put
libraries? (For MANY source packages the $PREFIX is /usr/local. The
only effect of it, since if ld.so chooses that library, it IS the one
that firefox will get, is a denial of service attack on firefox. Also,
it's damn near impossible to figure out what's wrong because there's no
error messages when you run firefox from the gui. It's just a hard
failure. I'm a software engineer and it had me stumped for months! I
asked on all the forums, got some me toos, but nobody had a clue, or
could even give me a path to follow to debug it. I didn't know about
apparmor at all. Hadn't heard of it. I also didn't get to run
realplayer because of this:

Dec 27 16:38:29 dell kernel: [412052.692079] type=1503
audit(1261960709.131:876): operation="open" pid=16346 parent=1
profile="/usr/lib/firefox-3.5*/firefox{,*[^s][^h]}" requested_mask="::r"
denied_mask="::r" fsuid=1002 ouid=0
name="/opt/real/RealPlayer/mozilla/nphelix.so"

I suppose you'd say there's no reason for firefox to access
/opt/real/RealPlayer/mozilla/** either, but these are normal
configurations, and on ubuntu with this setup, it fails for normal use.
That's user hostile.

Developers are normal users of ubuntu, no?
> Dave
>
>

I was going to wait to get the Security team to answer this, but I'm going to jump in before this gets out of hand and they can add the official answer later.

The apparmor profile is meant to allow access to standard applications using default configurations. Ubuntu does not install anything by default in /usr/local/lib . You said yourself that you built a custom gcc on your system. The idea is that is someone that is able to build a custom gcc, can also add /usr/local/lib to their apparmor profile. Regular users will not need to do either. As for RealPlayer, that's the standard path for their installer, so it's included.

Hopefully after the holiday, the Security team can give an official response. I suggest waiting for their response before continuing this discussion.

1) How would they know to add to their apparmor profile? There's no error message at any time that says that anything failed because of apparmor. Even running from a command line, there's no error message that says that apparmor denied access. If when using a gui, and something was blocked by apparmor a gui popup came up and told me so, and that I would have to modify a file in /etc/apparmor.d if I wanted to proceed, or better a mother-may-I that would do it for me, I would have a little more sympathy for your position, but really, doing development is a normal use of a Linux box. /usr/local/lib is a default location for many things, and not letting firefox load a library that ld.so presents to it is a denial of service. I understand that you want to make sure that firefox can't do something that I didn't ask it to do, but I did ask it, now didn't I?

2) The path for RealPlayer was NOT included. I just added it today. I was also trying to figure out for months why mplayer quit working embedded. I found others with the same problem, but no answers anywhere. Google for people wondering why nphelix.so won't load. You'll find plenty of thrashing about, but not one "add a new rule to a file in /etc/apparmor.d". I'm trying not to come across as security clueless, or worse as a luddite. I just don't agree that it is a security problem, to allow a program to load libraries ld.so wants to load for it.

From the man page for ld.so:

       The necessary shared libraries needed by the program are searched for
       in the following order

       o Using the environment variable LD_LIBRARY_PATH
              (LD_AOUT_LIBRARY_PATH for a.out programs). Except if the exe‐
              cutable is a setuid/setgid binary, in which case it is ignored.

       o From the cache file /etc/ld.so.cache which contains a compiled
              list of candidate libraries previously found in the augmented
              library path.

       o In the default path /lib, and then /usr/lib.

In my case, (as in normal) ld.so.conf, used by ldconfig to know where to look for libraries, the so called augmented security path, has only a line to include all the files found in the directory /etc/ld.so.conf.d, In that directory there's a file libc.conf that has a line /usr/local/lib. That makes ldconfig build the cache including libraries in /usr/local/lib. It's the purpose of the thing! It's been there since 2007, and things used to work just fine. Then after some update firefox started not working with never an error that mentioned security, nor apparmor. There's not a comment in /etc/ld.so.conf, nor a README in /etc/ld.so.conf.d, nor a section in the man pages ld.so(8), nor ldconfig(8), nor a helpful message printed by ldconfig the many times it ran as part of running apt-get upgrade, that would say, this won't work if you use apparmor unless you add rules to make it so. I can tell you that it hasn't been fun! I pretty quickly figured out that removing the libraries from /usr/local/lib was a work around, but it was months before I figured out why. I asked on ubuntu forums, in the gcc-help list, and many other pla...

The firefox AppArmor profile is supposed to be opt-in and disabled by default. Users are supposed to explicitly enable the profile for it to be used, as mentioned in https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview#New%20profiles. There was a bug in the packaging during the development cycle for 9.10 for people using daily builds or using firefox-3.5 on 9.04 and upgrading to 9.10. I'm somewhat concerned that the profile was enabled without you specifically enabling it, but if you hit the above bug or another admin enabled the profile, then that would explain it and I'm sorry for the inconvenience.

One of the reasons the profile is disabled by default is because of the issues discussed here, and also because the profile is still in development (though still quite useful for many users). Realplayer not working is simply a profile bug. /usr/local/lib is a different matter, and I would tend to agree with Micah's comment. That said, profiles are not only supposed to work in the default installation, but all common configurations. If there are 3rd party plugins that install to /usr/local, then this should be supported as well.

An AppArmor profile is intended to confine an application to a specific set of actions to proactively protect against flaws in the software it is trying to protect. Firefox is an extremely attractive target for attackers with 50+ CVEs in the software in 2009 alone, and having an AppArmor profile available for people to use is very important. IMO, too much autoconfiguration of the profile (ie, via ld.so.conf or other methods) makes it difficult to understand the profile and why it is working (or not working) the way it does, though we could probably just add /usr/local/lib to the profile.

Jamie Strandboge wrote:
> The firefox AppArmor profile is supposed to be opt-in and disabled by
> default. Users are supposed to explicitly enable the profile for it to
> be used, as mentioned in
> https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview#New%20profiles.
> There was a bug in the packaging during the development cycle for 9.10
> for people using daily builds or using firefox-3.5 on 9.04 and upgrading
> to 9.10.
That was me.
> One of the reasons the profile is disabled by default is because of the
> issues discussed here, and also because the profile is still in
> development (though still quite useful for many users).
For me as well.
> ... elsion... IMO, too
> much autoconfiguration of the profile (ie, via ld.so.conf or other
> methods) makes it difficult to understand the profile and why it is
> working (or not working) the way it does, though we could probably just
> add /usr/local/lib to the profile.
>
I certainly hope you do.

Fix committed to firefox-3.6.head. It will be in the next upload to Lucid.

This bug was fixed in the package firefox - 3.6.2+nobinonly-0ubuntu1

---------------
firefox (3.6.2+nobinonly-0ubuntu1) lucid; urgency=low

  * New upstream release v3.6.2 (FIREFOX_3_6_2_RELEASE)

  [ Felix Geyer <email address hidden> ]
  * Rebase mozilla-kde.patch for 3.6.2
    - update debian/patches/mozilla-kde.patch

  [ Jamie Strandboge <<email address hidden> > ]
  * AppArmor profile cleanup for Lucid users:
    - remove sys_ptrace now that the kernel DTRT (LP: #498317)
    - don't use @{PROC}/[0-9]*/mounts or /etc/gnome/defaults.list (part of
      gnome abstraction now)
    - don't use @{PROC}/[0-9]*/maps (part of base abstraction)
    - don't use /etc/sound (part of audio abstraction)
    - use 'owner' for Desktop and all dot files and directories in @{HOME}
    - use ubuntu-bittorrent-clients abstraction
    - use ubuntu-media-players abstraction
    - allow access to xubuntu default app list (LP: #500231)
    - add ark and xarchiver for KDE and XFCE archive managers
    - add thunar for XFCE
    - add editors supported by It's All Text, thanks to James Troup
      (LP: #507711)
    - allow RealPlayer plugin and access to /usr/local/lib (LP: #501822)
    - allow Ux for scim and scim-bridge
    - allow ix for gst-plugin-scanner
  * ship different AppArmor profiles for different releases:
    - move usr.bin.firefox.apparmor.in to usr.bin.firefox.apparmor.9.10
    - add usr.bin.firefox.apparmor.10.04
    - debian/rules: ship AppArmor profile based on release:
      + add DISTRIB, DISTRIB_VERSION_MAJOR and DISTRIB_VERSION_MINOR
      + ship 9.10 profile for Karmic and under and 10.04 profile for Lucid
        and later
  * update AppArmor profile to transition to a java child profile rather
    than Ux. This has the added benefit of restricting java a bit more than
    before. This is needed since the java plugins are expecting certain
    environment variables to be present, which get scrubbed with Ux. 'cx'
    doesn't remove these from the environment but allows for better profiling
    over 'ux'. Thanks to John Johansen for discussion and idea. (LP: #484148)

  [ Alexander Sack <email address hidden> ]
  * fix LP: #518422 - Firefox does not start with certain addons installed;
    don't normalize paths for xpti.dat
    - add debian/patches/lp518422.patch
    - update debian/series

  [ Micah Gersten <email address hidden> ]
  * Bump minimum system NSS to 3.12.6 after upstream landing of (bmo: 545755)
    aka Update Mozilla stable branches to NSS 3.12.6 and minimal support for
    RFC 5746
    - update debian/rules
  * Really fix FTBFS for sparc; Add configure flag to correct variable
    - update debian/rules
 -- Micah Gersten <email address hidden> Wed, 24 Mar 2010 01:17:46 -0500