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.
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.
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?
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?
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?
Exactly right, it does not matter since we are using dom0 kernel. Unless we are using pv grub:
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.
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.
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?
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?