Tor AppArmor profile prevents obfsproxy from starting

added apparmor component::applications/tor bundles/installation owner::weasel parent::5791 priority::high resolution::duplicate severity::normal status::closed type::defect labels

Yes, that's a known limitation. Looking forward to patches.

Ok. Is it ok if I just post the rules which need to be appended? The following work. I am not experienced with AppArmor, please leave feedback.

  ## obfsproxy
  /usr/local/lib/python2.7/** r,
  /var/log/tor/log rw,
  /dev/urandom r,
  /dev/random r,
  /usr/** r,
  /etc/python2.7/sitecustomize.py r,
  /usr/bin/obfsproxy rix,

I don't think Tor should have these privileges. Putting the obfsproxy profiles into tor just seems like a bad idea that won't scale.

I suspect the better way would be to allow starting obfsproxy in an unconfined manner, if that's possible.

I agree with weasel that Tor should not have all privs obfsproxy needs: else we're slowly defeating the whole idea of per-program confinement. It looks like either the Tor profile should start obfsproxy in an unconfined manner, or (better) the obfsproxy package should ship with its own AppArmor profile.

proper: by the way, it was almost pure chance that I was just pointed to this bug report. If weasel prefers such issues being reported here instead of on the Debian BTS, fine with me, but then you might want to point me at / Cc: me AppArmor-related issues.

Trac:
Cc: proper to proper, intrigeri@boum.org

Replying to intrigeri:

proper: by the way, it was almost pure chance that I was just pointed to this bug report. If weasel prefers such issues being reported here instead of on the Debian BTS

The Debian BTS is the canonical and preferred means to report bugs against the debian packages. Not everybody realizes that.

Replying to weasel:

I don't think Tor should have these privileges. Putting the obfsproxy profiles into tor just seems like a bad idea that won't scale.

Ok.

I suspect the better way would be to allow starting obfsproxy in an unconfined manner, if that's possible.

It's possible. In that case, look for.

  /{,var/}run/tor/control.authcookie.tmp rw,

  # Site-specific additions and overrides. See local/README for details.
  #include <local/system_tor>

Needs just one more line in between.

  /{,var/}run/tor/control.authcookie.tmp rw,

  /usr/bin/obfsproxy Ux,

  # Site-specific additions and overrides. See local/README for details.
  #include <local/system_tor>

Quoted from http://wiki.apparmor.net/index.php/QuickProfileLanguage:

x - execute
ux - Execute unconfined (preserve environment) -- WARNING: should only be used in very special cases
Ux - Execute unconfined (scrub the environment)

So that should do the trick. (Tested, works for me.)

Replying to intrigeri:

I agree with weasel that Tor should not have all privs obfsproxy needs: else we're slowly defeating the whole idea of per-program confinement.

Agreed.

It looks like either the Tor profile should start obfsproxy in an unconfined manner,

Ok. The change above should do it.

or (better) the obfsproxy package should ship with its own AppArmor profile.

I might create one, but please don't wait for me. If someone else has a smaller todo list and is faster, I am happy about that.

proper: by the way, it was almost pure chance that I was just pointed to this bug report. If weasel prefers such issues being reported here instead of on the Debian BTS, fine with me, but then you might want to point me at / Cc: me AppArmor-related issues.

Will do next time.

Replying to weasel:

The Debian BTS is the canonical and preferred means to report bugs against the debian packages. Not everybody realizes that.

Well, I created one @ trac.torproject.org as well since #5791 (moved) isn't Debian specific. So I am unsure how both projects could benefit best from such discussions and proposed changes.

Trac:
Status: new to needs_review

Reported as Debian bug 739279, with a patch attached. Note that in general, "Ux" is wrong, as it prevents using the dedicated profile for the executed application, even if it's available. Hence the use of PUx in my patch.

BTW, this ticket seems to be a duplicate of #6996 (closed).

Trac:
Cc: proper, intrigeri@boum.org to proper

FWIW, a guy in #tor with ubuntu trusty 14.04 encountered the same problem. Adding the apparmor rule line worked for him.

The fix is in 0.2.5.3-alpha-1 and above. Anyone who wants to see it in the 0.2.4.x packages, tell Weasel about it :)

When I restart tor, I got this message in the log: Failed to terminate process with PID '8165' ('Permission denied').

8165 was the PID of obfsproxy run by the previous tor session.

Maybe another apparmor rule is needed to be able to terminate and old obfsproxy ?

Trac:
Username: anant

Replying to anant:

When I restart tor, I got this message in the log: Failed to terminate process with PID '8165' ('Permission denied').

8165 was the PID of obfsproxy run by the previous tor session.

Maybe another apparmor rule is needed to be able to terminate and old obfsproxy ?

I don't think this is a problem with apparmor rules. More like #8746 (moved) or something.

Replying to anant:

When I restart tor, I got this message in the log: Failed to terminate process with PID '8165' ('Permission denied').

Could be the new signal mediation that landed into Ubuntu 14.04.

If that's the case: this AppArmor feature is not available in Debian yet, as the relevant kernel patches have not been upstream yet, so adding the needed lines to the AppArmor profile will prevent it from parsing on Debian. So, I think Ubuntu should add this line as a custom patch for the time being... or finish pushing their stuff upstream.

Trac:
Cc: proper to proper, intrigeri

See https://trac.torproject.org/projects/tor/ticket/13716#comment:5 for the current state of things, and next things to do. If nobody steps up to implement what's needed, then I suggest we stop shipping the AppArmor profile on Ubuntu.

Set all open tickets without a severity to "Normal"

Trac:
Severity: N/A to Normal

group tickets related to [[AppArmorForTBB]]/tor packages

Trac:
Keywords: N/A deleted, apparmor added

Duplicate of #6996 (closed).

Trac:
Sponsor: N/A to N/A
Resolution: N/A to duplicate
Status: needs_review to closed
Reviewer: N/A to N/A

closed

Tor AppArmor profile prevents obfsproxy from starting

Child items 0

Activity