Opened 5 years ago

Closed 14 months ago

#13716 closed defect (wontfix)

Tor daemon apparmor profile breaks bridge restarts on Ubuntu 14.04

Reported by: vladtsyrklevich Owned by: weasel
Priority: Medium Milestone:
Component: Applications/Tor bundles/installation Version:
Severity: Normal Keywords: obfsproxy, apparmor
Cc: micahlee, intrigeri, adrelanos@…, miked, u@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


As intrigeri noted here a new apparmor mediation for signals in 14.04 breaks tor being able to kill obfsproxy on restart (meaning it comes up without obfsproxy since the old process continues holding on to the open port.) Example syslog:
type=1400 audit(1415580423.404:19): apparmor="DENIED" operation="signal" profile="system_tor" pid=4514 comm="tor" requested_mask="send" denied_mask="send" signal=term peer="unconfined"

He also mentioned that adding the correct rule would break Debian, so an Ubuntu-specific fix was needed.

The rule that needs to be added is:
signal (send) set=("term") peer="unconfined",

Not sure if the easiest path is to wait out Debian upgrading, updating Ubuntu packages, or adding an Ubuntu specific install line in Tor's apt package

Child Tickets

Change History (12)

comment:1 Changed 5 years ago by erinn

Cc: micahlee added
Owner: changed from erinn to weasel
Status: newassigned

Reassigning to weasel since he handles Debian/Ubuntu packages and adding Micah Lee to cc since he mentioned apparmor profiles breaking torbrowser-launcher updates on Ubuntu and this might be related.

comment:2 Changed 5 years ago by arma

Cc: intrigeri added

comment:3 Changed 5 years ago by intrigeri

Debian won't "upgrade" until the kernel support for signal mediation reaches Linux mainline. So, either someone contributes patches to the packaging scripts that implement Ubuntu-specific tricks (I won't do that personally), assuming weasel is fine with taking such a patch... or we should stop installing the AppArmor profile on Ubuntu.

comment:4 Changed 5 years ago by vladtsyrklevich

My analysis was missing one detail earlier. If Debian is going to eventually add this AA mediation, the package is going to need to figure out whether or not include this mediation anyway so this will likely be necessary for Debian anyway. A simple solution here would be just to add something like:

if [ -d /sys/kernel/security/apparmor/features/signal ]; then
  echo 'signal (send) set=("term") peer="unconfined",' >>/etc/apparmor.d/local/system_tor
  apparmor_parser -r /etc/apparmor.d/system_tor
Last edited 5 years ago by vladtsyrklevich (previous) (diff)

comment:5 Changed 5 years ago by intrigeri

I missed something in my previous comment: in Debian testing/sid, we now have AppArmor 2.9, whose parser silently ignores rules that require unavailable kernel features. So, adding the signal rules that Ubuntu needs will be a no-op on Jessie/sid. Therefore, we could add them to the default profile, but then the packages build scripts need to remove it when building for any distribution that ships anything older that AppArmor 2.9 or 2.8+tons_of_Ubuntu_patches (not sure which ones exactly will work), such as Debian Wheezy, and probably older Ubuntu releases too.

Hoping that's enough for the Ubuntu folks to know what they should now do :)

comment:6 Changed 5 years ago by intrigeri

If nobody steps up to implement what's needed, then I suggest we stop shipping the AppArmor profile on Ubuntu.

comment:7 Changed 5 years ago by proper

Cc: adrelanos@… added

comment:8 Changed 5 years ago by miked

Cc: miked added

comment:9 Changed 5 years ago by u

Cc: u@… added

comment:10 Changed 2 years ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:11 Changed 15 months ago by traumschule

Keywords: obfsproxy apparmorobfsproxy, apparmor

group tickets related to AppArmorForTBB/tor packages

comment:12 Changed 14 months ago by gk

Resolution: wontfix
Status: assignedclosed

obfsproxy is long gone from our list of supported pluggable transports. Closing this as WONTFIX. Please open a new ticket if that's still an issue with supported pluggable transports. Thanks!

Note: See TracTickets for help on using tickets.