Why is Tor Browser allowed to connect to /var/run/anon-ws-disable-stacked-tor/127.0.0.1_9150.sock by the current AppArmor profile?

[Patrick]

I wanted to update https://github.com/Whonix/apparmor-profile-torbrowser so it keeps working since Tor Project changed TBB to SocksSocket. Strangely it is not required.

I wonder why Tor Browser is able to connect to these unix domain sockets as its not allowed by the profile.

• /var/run/anon-ws-disable-stacked-tor/127.0.0.1_9150.sock
• /var/run/anon-ws-disable-stacked-tor/127.0.0.1_9151.sock

sudo aa-status shows the Tor Browser AppArmor profile is loaded and enforced.

Related:

• https://phabricator.whonix.org/T192
• https://forums.whonix.org/t/tor-browser-6-5a4-connectivity-broken-blocked-by-apparmor-profile-since-tbb-changed-to-sockssocket

[entr0py]

• Confirmed your conclusion that TBB 6.5a4-hardened works with new environment variables without changing apparmor.
• Added explicit deny rules to apparmor profile.
  deny /var/run/anon-ws-disable-stacked-tor/127.0.0.1_9150.sock rw,
deny /var/run/anon-ws-disable-stacked-tor/127.0.0.1_9151.sock rw,
  TBB continues to work without issue.

Background info from: http://man7.org/linux/man-pages/man7/unix.7.html

On Linux, connecting to a stream socket object requires write
permission on that socket; sending a datagram to a datagram socket
likewise requires write permission on that socket. POSIX does not
make any statement about the effect of the permissions on a socket
file, and on some systems (e.g., older BSDs), the socket permissions
are ignored. Portable programs should not rely on this feature for
security.

Relevant bug report? https://bugs.launchpad.net/apparmor/+bug/1208988

• AppArmor removed unix domain socket mediation as part of the 2.4 (karmic) rewrite to the security_path hooks so that it could be upstreamed into the main kernel. The result being apparmor no longer mediates access to AF_UNIX socket files. Or more specifically it does not mediation connections between sockets, creation of a socket within the filesystem is mediated

• Confined applications can currently read from and write to any AF_UNIX
  socket files

• Existing AppArmor profiles that contain file rules granting write access to
  AF_UNIX socket files are effectively being ignored

So IIUC apparmor can control socket creation and destruction but not read/write to existing sockets. It says “Fix Released”. Is that to upstream AppArmor? Where is the corresponding Debian report?

[Patrick]

https://udd.debian.org/bugs.cgi?release=jessie&merged=ign&fnewerval=7&flastmodval=7&apparmor=1&sortby=id&sorto=asc#results

Maybe there is no Debian bug report.

Could you try upgrading your linux kernel and apparmor package to stretch please in a test VM? See if it is fixed there?

[entr0py]

Could you try upgrading your linux kernel and apparmor package to stretch please in a test VM?

Wow, what a miserable assignment (when you have no idea how to do this)…

The answer first:

As of Debian Linux kernel 4.8.5, apparmor still does not enforce read/write policies on domain sockets. Stretch is supposed to ship with 4.10 so there’s a chance that a fix may make it by then.

Now some questions:

• First I tried upgrading just the kernel in a Virtualbox Whonix-13 Workstation. Then I tried dist-upgrading the whole workstation to stretch. Neither method worked. Can’t remember exactly why but I think I couldn’t get X operational again. Mentioning this in case there’s some easy way to do this.
• So I started with a fresh Debian stretch install. Installed TBB, apparmor profile, anon-ws-disable-stacked-tor (11/22 commit). Hacked around with anon-shared-helper-scripts until I got the correct GATEWAY_IP. Restarted service to get correct socat mappings. TBB was fully functional, including control port. Added deny rule to apparmor profile. Reloaded. No effect.
• I did this in Virtualbox for the Whonix images and then moved back to Qubes with a Debian HVM. One thing I’d like to know is: Does the Linux kernel in Qubes-Whonix VMs matter at all since we are using Qubes PV kernels? So even if this gets fixed by 4.10, it might not matter for Qubes users because Qubes PV kernel might be older? Is that right?

[Patrick]

Thanks so much for taking this assignment! I guess more than a justifiable amount of work has been spend to justify reporting a bug against Debain. Could you open a bug against Debian please?

Does the Linux kernel in Qubes-Whonix VMs matter at all since we are using Qubes PV kernels?

Exactly right, it does not matter since we are using dom0 kernel. Unless we are using pv grub:

Managing VM kernel

So even if this gets fixed by 4.10, it might not matter for Qubes users because Qubes PV kernel might be older? Is that right?

Yes.

[torjunkie]

FWIW

The apparmor profile also doesn’t block the connection to the Socks port when Qubes dom0 kernel is upgraded to the latest available from the unstable repo i.e. 4.8.9-12

Since that is only 4 days old, it looks like the problem is yet to be sorted.

[Patrick]

So this might be a bug in both Debian and Fedora kernels. The root cause may even be a missing patch in the mainline Linux kernel. Is there a Linux bug report yet?

Debian changelog for apparmor mentions UNIX domain sockets.

http://metadata.ftp-master.debian.org/changelogs/main/a/apparmor/unstable_changelog

Am I inflating this or doesn’t this bug totally render apparmor useless? Isn’t there some unix domain socket, once access can compromise the whole system?

[torjunkie]

No idea. Beyond my pay grade!