4

BTW, I don't mean root, just a plain user. I'm worried because I'm scared that if I do such things I could infect my Chromium folder. I got a huge case of OCD.

RoundDuckMan
  • 171
  • 7

2 Answers2

4

The short answer is: if your Firefox is compromised, it can do whatever it wants. It can modify whatever files it wants. It can even keylog and get root. But there are a few ways you can improve your security, like using a more secure browser, AppArmor or the NoScript plugin. The long answer is...

Yes, if your Firefox process is compromised, it can do absolutely anything your regular user can do. In Linux, security comes from separation of users. I talked a little about the risks of assuming you have intra-user protection here. Basically, your system has security checks all over, and if two process' are of the same user, then they are considered to be equally trusted, and can interfere with each other at will. This includes keylogging, which means they can sniff your root password next time you type it in. Or it could inject keystrokes, move the mouse, modify all files in your home directory and many files outside of it. It could access the network at will, and pretty much everything else. If your Firefox process is compromised, you have much more to worry about than your Chromium folder being modified. Firefox runs as your user. Your user is you. Malware that breaks out of Firefox inherits that privilege, and will be able to do whatever you can do, such as the few examples I gave above.

Also note that Chromium is significantly more secure than Firefox. While Firefox has no proactive security mechanisms whatsoever, Chromium has them in abundance (suid chroot sandbox, seccomp-bpf sandbox, several types of namespace sandboxes, and more). In many contents, Firefox is almost always the first to be hacked, with Chrome/Chromium surviving the longest, and taking the longest for world-expert hackers to find ways through all the sandbox layers. If your primary goal is security, you might want to stick with using just Chromium.

If you still want to use Firefox though, you get mitigate this to a large extent by using a sandbox that comes with Linux. Ubuntu has the AppArmor sandbox, so you can use it to protect your browsers, among other things. I don't know how up to date it is, but the instructions for enabling it can be found here. AppArmor is a type of sandbox called a MAC, or Mandatory Access Control, which is controlled by the kernel, the core and boss of the operating system which runs with even more privileges than root. When an AppArmor profile is enabled, it tells the kernel to restrict what folders and files a process is allowed to access. The AppArmor profile for Firefox is written to give it only the permissions it needs, and nothing else. If it tries to access anything it's not allowed to, the kernel will promptly deny access.

Here is the default Firefox AppArmor policy for Ubuntu 14.04, which you can look at to get an idea of how it works. As you can see, it allows read access to most folders, but only allows writing to configuration folders related to Firefox. Chromium folders are not in the whitelisted paths, and any attempts to write there would be denied.

# vim:syntax=apparmor
# Author: Jamie Strandboge <jamie@canonical.com>

# Declare an apparmor variable to help with overrides
@{MOZ_LIBDIR}=/usr/lib/firefox

#include <tunables/global>

# We want to confine the binaries that match:
#  /usr/lib/firefox/firefox
#  /usr/lib/firefox/firefox
# but not:
#  /usr/lib/firefox/firefox.sh
/usr/lib/firefox/firefox{,*[^s][^h]} {
  #include <abstractions/audio>
  #include <abstractions/cups-client>
  # TODO: finetune this for required accesses
  #include <abstractions/dbus>
  #include <abstractions/dbus-accessibility>
  #include <abstractions/dbus-session>
  #include <abstractions/gnome>
  #include <abstractions/ibus>
  #include <abstractions/nameservice>
  #include <abstractions/p11-kit>

  # Addons
  #include <abstractions/ubuntu-browsers.d/firefox>

  # for networking
  network inet stream,
  network inet6 stream,
  @{PROC}/[0-9]*/net/if_inet6 r,
  @{PROC}/[0-9]*/net/ipv6_route r,
  @{PROC}/[0-9]*/net/dev r,
  @{PROC}/[0-9]*/net/wireless r,

  # should maybe be in abstractions
  /etc/ r,
  /etc/mime.types r,
  /etc/mailcap r,
  /etc/xdg/*buntu/applications/defaults.list    r, # for all derivatives
  /etc/xfce4/defaults.list r,
  /usr/share/xubuntu/applications/defaults.list r,
  owner @{HOME}/.local/share/applications/defaults.list r,
  owner @{HOME}/.local/share/applications/mimeapps.list r,
  owner @{HOME}/.local/share/applications/mimeinfo.cache r,
  owner /tmp/** m,
  owner /var/tmp/** m,
  /tmp/.X[0-9]*-lock r,
  /etc/udev/udev.conf r,
  # Doesn't seem to be required, but noisy. Maybe allow 'r' for 'b*' if needed.
  # Possibly move to an abstraction if anything else needs it.
  deny /run/udev/data/** r,

  /etc/timezone r,
  /etc/wildmidi/wildmidi.cfg r,

  # firefox specific
  /etc/firefox*/ r,
  /etc/firefox*/** r,
  /etc/xul-ext/** r,
  /etc/xulrunner-2.0*/ r,
  /etc/xulrunner-2.0*/** r,
  /etc/gre.d/ r,
  /etc/gre.d/* r,

  # noisy
  deny @{MOZ_LIBDIR}/** w,
  deny /usr/lib/firefox-addons/** w,
  deny /usr/lib/xulrunner-addons/** w,
  deny /usr/lib/xulrunner-*/components/*.tmp w,
  deny /.suspended r,
  deny /boot/initrd.img* r,
  deny /boot/vmlinuz* r,
  deny /var/cache/fontconfig/ w,
  deny @{HOME}/.local/share/recently-used.xbel r,

  # TODO: investigate
  deny /usr/bin/gconftool-2 x,

  # These are needed when a new user starts firefox and firefox.sh is used
  @{MOZ_LIBDIR}/** ixr,
  /usr/bin/basename ixr,
  /usr/bin/dirname ixr,
  /usr/bin/pwd ixr,
  /sbin/killall5 ixr,
  /bin/which ixr,
  /usr/bin/tr ixr,
  @{PROC}/ r,
  @{PROC}/[0-9]*/cmdline r,
  @{PROC}/[0-9]*/mountinfo r,
  @{PROC}/[0-9]*/stat r,
  owner @{PROC}/[0-9]*/task/[0-9]*/stat r,
  @{PROC}/[0-9]*/status r,
  @{PROC}/filesystems r,
  /sys/devices/pci[0-9]*/**/uevent r,
  owner @{HOME}/.thumbnails/*/*.png r,

  /etc/mtab r,
  /etc/fstab r,

  # Needed for the crash reporter
  owner @{PROC}/[0-9]*/environ r,
  owner @{PROC}/[0-9]*/auxv r,
  /etc/lsb-release r,
  /usr/bin/expr ix,
  /sys/devices/system/cpu/ r,
  /sys/devices/system/cpu/** r,

  # about:memory
  owner @{PROC}/[0-9]*/statm r,
  owner @{PROC}/[0-9]*/smaps r,

  # Needed for container to work in xul builds
  /usr/lib/xulrunner-*/plugin-container ixr,

  # allow access to documentation and other files the user may want to look
  # at in /usr and /opt
  /usr/ r,
  /usr/** r,
  /opt/ r,
  /opt/** r,

  # so browsing directories works
  / r,
  /**/ r,

  # Default profile allows downloads to ~/Downloads and uploads from ~/Public
  owner @{HOME}/ r,
  owner @{HOME}/Public/ r,
  owner @{HOME}/Public/* r,
  owner @{HOME}/Downloads/ r,
  owner @{HOME}/Downloads/* rw,

  # per-user firefox configuration
  owner @{HOME}/.{firefox,mozilla}/ rw,
  owner @{HOME}/.{firefox,mozilla}/** rw,
  owner @{HOME}/.{firefox,mozilla}/**/*.{db,parentlock,sqlite}* k,
  owner @{HOME}/.{firefox,mozilla}/plugins/** rm,
  owner @{HOME}/.{firefox,mozilla}/**/plugins/** rm,
  owner @{HOME}/.gnome2/firefox*-bin-* rw,
  owner @{HOME}/.cache/mozilla/{,firefox/} rw,
  owner @{HOME}/.cache/mozilla/firefox/** rw,
  owner @{HOME}/.cache/mozilla/firefox/**/*.sqlite k,

  #
  # Extensions
  # /usr/share/.../extensions/... is already covered by '/usr/** r', above.
  # Allow 'x' for downloaded extensions, but inherit policy for safety
  owner @{HOME}/.mozilla/**/extensions/** mixr,

  deny @{MOZ_LIBDIR}/update.test w,
  deny /usr/lib/mozilla/extensions/**/ w,
  deny /usr/lib/xulrunner-addons/extensions/**/ w,
  deny /usr/share/mozilla/extensions/**/ w,
  deny /usr/share/mozilla/ w,

  # Miscellaneous (to be abstracted)
  # Ideally these would use a child profile. They are all ELF executables
  # so running with 'Ux', while not ideal, is ok because we will at least
  # benefit from glibc's secure execute.
  /usr/bin/mkfifo Uxr,  # investigate
  /bin/ps Uxr,
  /bin/uname Uxr,

  # Site-specific additions and overrides. See local/README for details.
  #include <local/usr.bin.firefox>
}

Another way to mitigate this is by using NoScript. It allows you to block dangerous JavaScript, Flash, etc from websites, which makes attacks on Firefox much less likely to succeed. Even if you keep most scripts enabled because disabling scripts causes many websites to not work as expected, the plugin still provides transparent protection from other threats, such as clickjacking and XSS. It's a very popular plugin and very well regarded in the security community. I highly recommend you install it, in addition to enabling AppArmor, if your goal is to minimize the risk of a malicious website compromising your computer or any files on it.

forest
  • 64,616
  • 20
  • 206
  • 257
  • I got Ubuntu GNOME 15.10, so I'm pretty much fine? Also does this apply to an install of firefox-developer-edition via ubuntu make? EDIT: Found out it isn't on by default for both. Well must activate it now... – RoundDuckMan Apr 10 '16 at 02:28
  • It's not enabled by default because it doesn't always work on all systems. But it still works for most people, so it should be safe to enable it. You can always tweak it or disable it if it doesn't work properly. You can test it by trying to save a file outside of your Downloads directory. If everything is protected, it shouldn't save outside. I hope this helps. :) – forest Apr 10 '16 at 03:05
  • Is there a way to make one for firefox-dev installed from ubuntu-make as well? Or should I ask this on askubuntu? – RoundDuckMan Apr 10 '16 at 03:16
  • You should probably ask that on askubuntu, or search for it on the web yourself. I would answer if I knew, but I use a different distro. I imagine that the regular Firefox profile should work for the dev version as well, as long as the location of the Firefox binary is /usr/bin/firefox. Is there any reason you need the dev version though? It's not any more secure, and sometimes can be less secure (due to having untested features). – forest Apr 10 '16 at 03:30
  • Might use it for some web development (maybe not though) and to see the in development features. – RoundDuckMan Apr 10 '16 at 03:41
  • This answer is just wrong, even back when this answer was written, but it's more wrong now that Firefox actually had content sandboxes. Firefox sandbox and security design are very different from Chrome's, due to fundamental philosophical differences, but it's not less secure. There are many places where Firefox security design is much better and more advanced than Chrome. For example, Firefox's JavaScript engine's permission system that enables Xray vision on webextensions; container tabs; the anonymization features on EME sandboxing; etc. – Lie Ryan Feb 16 '19 at 16:07
  • @LieRyan I'd love to discuss this in more detail in the DMZ if you wish, but unfortunately as of 2019, Firefox is still much less secure than Chrome/Chromium both in theory and practice. The new privacy and tab isolation features are awesome though, but that's not directly related to security. – forest Feb 17 '19 at 10:02
  • @LieRyan You are correct that, when it comes to installing malicious extensions, Firefox is no longer as insecure with the WebExtensions API as it was when it used XUL. My answer was more focused towards exploiting vulnerabilities in the code, and that part is still (as of now) accurate. – forest Feb 17 '19 at 10:08
  • @LieRyan, I made an answer to my question that mentions the current state of Firefox since Quantum. Yeah, it's much better now. – RoundDuckMan Feb 21 '19 at 10:00
  • @forest What's wrong with modern Firefox now? Don't they have at least almost as strong security as Chrome? Don't forget some recent updates that buffed up the security further on Linux and maybe Mac. – RoundDuckMan Feb 21 '19 at 10:01
  • @RoundDuckMan No, it's still significantly less secure for both architectural reasons and sandbox reasons. Just a few examples: The use of jemalloc with its large heap sizes, PresArena being inferior to Chrome's PartitionAlloc, no GPU isolation for X11 (not sure how it works on Windows), no research into CFI or vtable protection, the use of NSS with quite a few side-channel attacks, insistence on fixing only severe bugs in their ESR releases (making exploit chaining easier), almost no systematic fuzzing of used libraries, etc. – forest Feb 21 '19 at 10:32
  • When it comes to the security of extensions, Firefox is now about as secure as Chrome since its extension API is less powerful (that's a bad thing IMO since it has severely crippled NoScript which is a now a ghost of its former self, but it does protect from malicious extensions). The biggest problem with Firefox is not lack of security features since they're at least _trying_ to get a seccomp sandbox and per-tab process isolation mature, but the quality of the code and the lack of systematic security analysis, static or dynamic. – forest Feb 21 '19 at 10:33
2

This is a bit of a later update on the situation, but it seems that Firefox doesn't suffer this problem anymore as of pretty much any version from 57 (the first Quantum release) and later. WebExtensions has sandboxing, and there seems to even be sandboxing in how Firefox views your local files, like Chrome/Chromium. Details about this are in https://wiki.mozilla.org/Security/Sandbox#Linux

EDIT/Note: That said, I still marked the answer above the ideal answer and upvoted it, as it once applied to Firefox and still applies to many of its forks, like Waterfox and Pale Moon

RoundDuckMan
  • 171
  • 7