Opened 4 years ago

Last modified 12 days ago

#9460 needs_review defect

Tor AppArmor profile prevents obfsproxy from starting

Reported by: proper Owned by: weasel
Priority: High Milestone:
Component: Applications/Tor bundles/installation Version:
Severity: Normal Keywords:
Cc: proper, intrigeri Actual Points:
Parent ID: #5791 Points:
Reviewer: Sponsor:

Description

On Debian testing (jessi).

Aug 12 19:18:03 host kernel: [84758.245866] type=1400 audit(1376335083.727:270): apparmor="DENIED" operation="exec" parent=7228 profile="system_tor" name="/usr/bin/obfsproxy" pid=7290 comm="tor" requested_mask="x" denied_mask="x" fsuid=112 ouid=0

And subsequently, use of obfuscated bridges is not possible while the AppArmor profile is load.

Child Tickets

Change History (16)

comment:1 Changed 4 years ago by weasel

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

comment:2 Changed 4 years ago by proper

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,

comment:3 Changed 4 years ago by 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.

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

comment:4 Changed 4 years ago by intrigeri

Cc: intrigeri@… added

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.

comment:5 in reply to:  4 ; Changed 4 years ago by weasel

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.

comment:6 in reply to:  5 Changed 4 years ago by proper

Status: newneeds_review

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 isn't Debian specific. So I am unsure how both projects could benefit best from such discussions and proposed changes.

comment:7 Changed 4 years ago by intrigeri

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.

comment:8 Changed 4 years ago by intrigeri

Cc: intrigeri@… removed

comment:9 Changed 4 years ago by asn

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

comment:10 Changed 4 years ago by intrigeri

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 :)

comment:11 Changed 4 years ago by 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 ?

comment:12 in reply to:  11 Changed 4 years ago by asn

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 or something.

comment:13 in reply to:  11 Changed 4 years ago by intrigeri

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.

comment:14 Changed 3 years ago by intrigeri

Cc: intrigeri added

comment:15 Changed 3 years ago by 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.

comment:16 Changed 12 days ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

Note: See TracTickets for help on using tickets.