Opened 4 months ago

Last modified 4 months ago

#31031 new defect

Tor Browser trying to read /etc/machine-id on start

Reported by: rain-undefined Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: sysrqb Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Steps to reproduce:

  • Tor Browser from the official website
  • Download and enable the AppArmor profile from https://github.com/Whonix/apparmor-profile-torbrowser (you may need to modify 2 or 3 lines due to different naming, e.g. change *-browser to *-browser*)
  • Start TorBrowser
  • Inspect /var/log/kern.log

You'll see a message like
Jun 29 01:23:45 debian kernel: [xxxxxx.xxxxxx] audit: type=1400 audit(xxxxxxxxxx.xxx:xx): apparmor="DENIED" operation="open" profile="/**/*-browser*/Browser/firefox" name="/etc/machine-id" pid=xxxx comm="firefox.real" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Not sure if this behaviour is also present in Firefox, maybe test it when I have time.

---
Debian 10 "Buster"
Tor Browser 8.5.3
AppArmor 2.13.2-10

Child Tickets

Change History (2)

comment:1 Changed 4 months ago by gk

Cc: sysrqb added

sysrqb pointed to:

if (allowPulse) {
    // PulseAudio also needs access to read the $XAUTHORITY file (see
    // bug 1384986 comment #1), but that's already allowed for hybrid
    // GPU drivers (see above).
    policy->AddPath(rdonly, "/var/lib/dbus/machine-id");
  }

However, a bit above that we have:

  bool allowPulse = false;
  bool allowAlsa = false; 
  if (level < 4) {
#ifdef MOZ_PULSEAUDIO
    allowPulse = true;
#endif

If you look at the sandbox level in about:config security.sandbox.content.level gives you 4. And even GetEffectiveContentSandboxLevel() (which determines level) seems to give 4 back:

#ifdef XP_LINUX
  // Level 4 and up will break direct access to audio.
  if (level > 3 && !Preferences::GetBool("media.cubeb.sandbox")) {
    level = 3;
  }
#endif

  return level;

given that media.cubeb.sandbox is true.

So, it seems that content at least is not the culprit here.

comment:2 Changed 4 months ago by rain-undefined

Update: this may be related to an earlier ticket https://trac.torproject.org/projects/tor/ticket/20884 .

For me the Tor Browser does not crash, and works happily even though it is denied /etc/machine-id. It does become unable to communicate with other applications using I-Bus (an example being my input method), which I think is expected after reading yawning's comment under that ticket.

And if I include <abstractions/dbus-session-strict> (which will permit the browser to read /etc/machine-id) and <abstractions/ibus> in the profile, TB will start to work with I-Bus applications again.

---
Also, thanks gk & sysrqb for working on this (although i cannot understand much yet)

Note: See TracTickets for help on using tickets.