Bug #10836

Investigate why the Tor Browser AppArmor profile allows starting Totem

Added by intrigeri 2016-01-02 05:36:26 . Updated 2016-07-19 08:55:45 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_2.5
Start date:
2016-01-02
Due date:
% Done:

100%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Browser
Deliverable for:

Description

  1. Copy a video that’s not supported by Tor Browser (e.g. .flv) to ~/Tor Browser/.
  2. Open Tor Browser
  3. In about:config, set browser.download.forbid_open_with to false.
  4. Visit ~/Tor Browser/ and click the unsupported video.
  5. Choose “Open with” -> “Videos (default)”
  6. After a while Totem plays the video; in ps faux it’s not a child process of Firefox; Totem is running under its own (enforced) AppArmor profile.

Subtasks

Related issues

Related to Tails - Bug #11579: Research what to do wrt. D-Bus activatable apps and AppArmor Confirmed 2016-07-19

History

#1 Updated by intrigeri 2016-01-02 05:37:34

  • Priority changed from Normal to Elevated
  • Target version set to Tails_2.0

I’ll check if it’s a regression since 1.8.1 (this is the part that is higher than normal prio).

It might be that we’ve giving Tor Browser access to the session’s D-Bus, which might allow things like that.

#2 Updated by intrigeri 2016-01-02 10:17:34

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

Seems like the base abstraction is enough:

root@amnesia:/etc/apparmor.d# aa-exec -p empty /usr/bin/totem

(totem:16552): GLib-GIO-ERROR **: No GSettings schemas are installed on the system
Trace/breakpoint trap

root@amnesia:/etc/apparmor.d# cat empty 
# vim:syntax=apparmor

#include <tunables/global>

profile empty {
  #include <abstractions/base>
}

I’ve asked on the AppArmor list if it’s expected. In any case, Totem will still have access to the same files as the ones we allow Tor Browser, so we should be fine.

#3 Updated by intrigeri 2016-01-02 10:47:57

  • Subject changed from Investigate why Tor Browser can start Totem on 2.0~beta1 to Investigate why the Tor Browser AppArmor profile allows starting Totem
  • Priority changed from Elevated to Normal
  • Target version changed from Tails_2.0 to Tails_2.2

On 1.8.1 the same commands give me a similar result:

root@amnesia:~# aa-exec -p empty /usr/bin/totem
No protocol specified

(totem:7284): Gtk-WARNING **: cannot open display: :0.0

=> not a regression, I’ll come back to it later.

#4 Updated by intrigeri 2016-02-12 23:49:37

  • Target version changed from Tails_2.2 to Tails_2.3

#5 Updated by intrigeri 2016-04-16 15:41:03

  • Target version changed from Tails_2.3 to Tails_2.4

#6 Updated by intrigeri 2016-05-07 07:37:30

  • Target version changed from Tails_2.4 to Tails_2.5

#7 Updated by intrigeri 2016-07-19 07:49:48

Actually, my tests with aa-exec were flawed.

#8 Updated by intrigeri 2016-07-19 08:09:54

  • Description updated

#9 Updated by intrigeri 2016-07-19 08:50:49

If I run Tor Browser from a terminal where DBUS_SESSION_BUS_ADDRESS is unset, it can’t start Totem and complains: ** (firefox:14725): WARNING **: Cannot launch application: Failed to execute child process "totem" (Permission denied), and the Journal confirms that AppArmor blocked execution of Totem by Tor Browser.

Same if I set DBusActivatable=false in /usr/share/applications/org.gnome.Totem.desktop.

So, it seems that unfiltered access to the session D-Bus bus allows a confined application to have the session’s dbus-daemon execute any D-Bus activatable app. The executed application will run under its own AppArmor profile, if it has one, and unconfined otherwise. In Tails 2.4, the D-Bus activatable applications we ship are: Totem, Nautilus, Screenshot, PortalHelper and gedit.

So the next question is: is it acceptable? How can an attacker, who controls Tor Browser, leverage this to do stuff they should be forbidden to? Shall we make all apps non-D-Bus-activatable? All these questions keeping in mind that to get working input systems and accessibility support, we need to give Tor Browser access to the session bus anyway (and unfiltered access until the kernel patches needed to filter D-Bus calls make it into mainline Linux). I’ll file a ticket to research that.

#10 Updated by intrigeri 2016-07-19 08:52:25

#11 Updated by intrigeri 2016-07-19 08:55:11

  • related to Bug #11579: Research what to do wrt. D-Bus activatable apps and AppArmor added

#12 Updated by intrigeri 2016-07-19 08:55:45

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)
  • % Done changed from 10 to 100

Problem understood, next step is Bug #11579.