Opened 7 years ago

Closed 5 years ago

#6996 closed defect (fixed)

Problems with starting managed Obfsproxy server when installed via debian package and with Tor as service

Reported by: linda Owned by: asn
Priority: Medium Milestone:
Component: Archived/Obfsproxy Version: Tor: 0.2.5.1-alpha
Severity: Keywords:
Cc: weasel Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

On a Ubuntu 12.04 "precise" host, I have installed obfsproxy and upgraded tor via the debian packages. More specifically:

$> sudo apt-get install -y tor obfsproxy
...
$> which obfsproxy
/usr/bin/obfsproxy
$> obfsproxy --version
obfsproxy 0.1.4 (git-94ebc4c3edf1e3e5)
$> tor --version
 [notice] Tor v0.2.3.22-rc (git-4a0c70a817797420) running on Linux.
 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Tor version 0.2.3.22-rc (git-4a0c70a817797420).

I'm typically managing Tor via:

$> sudo service tor start|stop|status

My torrc is:

$> grep -v "^#" /etc/tor/torrc | sed '/^$/d'
SocksPort 0
RunAsDaemon 1
User debian-tor
ORPort 8888
Nickname sricslbridge2
ExitPolicy reject *:* # no exits allowed
BridgeRelay 1
ServerTransportPlugin obfs2 exec /usr/bin/obfsproxy --managed

After starting Tor, the following process is running. But the obfsproxy process is missing, because of the following log output:

$> ps axu | grep tor
107       2228  0.7  1.3 379396 53244 ?        Sl   07:27   0:01 /usr/sbin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc --hush
...
$> ps axu | grep obfs
$> sudo grep obfs /var/log/tor/log
 [warn] Could not launch managed proxy executable at '/usr/bin/obfsproxy' ('Permission denied').

When I turn Log on via torrc, the log output is slightly more verbose:

$> sudo grep -v "^#" /etc/tor/torrc | grep Log
Log debug file /var/log/tor/debug.log
$> sudo grep obfs /var/log/tor/debug.log
 [info] launch_managed_proxy(): Managed proxy at '/usr/bin/obfsproxy' has spawned with PID '2423'.
 [info] handle_proxy_line(): Got a line from managed proxy '/usr/bin/obfsproxy': (ERR: Failed to spawn background process - code 9/D)
 [warn] Could not launch managed proxy executable at '/usr/bin/obfsproxy' ('Permission denied').

The reason I was thinking it has to do with my init script (although I don't think I changed it myself. It was probably installed with Tor 0.2.2.x originally), is that I tried to run multiple Tor processes controlled via init.d using the instructions here:

https://www.torservers.net/wiki/setup/server#multiple_tor_processes

And the effect was that obfsproxy did start using this alternative init script. However, I reverted back to the original init script because the stopping of multiple Tor processes didn't work and I realized that I only need one Tor process to support a regular and an obfuscated bridge.

In the hope that the permission required to start the managed obfsproxy had to do with write permissions in certain locations, I attempted: (but it didn't resolve the problem)

$> sudo chown -R debian-tor:adm /var/tor
$> sudo ls -la /var/tor
total 6816
drwx------  3 debian-tor adm     4096 Sep 28 15:27 .
drwxr-xr-x 13 root       root    4096 Sep 29 07:23 ..
-rw-------  1 debian-tor adm    16947 Sep 28 13:11 cached-certs
-rw-------  1 debian-tor adm   706188 Sep 28 13:11 cached-consensus
-rw-------  1 debian-tor adm  4237891 Sep 28 14:36 cached-descriptors
-rw-------  1 debian-tor adm   184873 Sep 28 14:38 cached-descriptors.new
-rw-------  1 debian-tor adm   594762 Sep 28 13:11 cached-microdesc-consensus
-rw-------  1 debian-tor adm  1172036 Sep 28 14:36 cached-microdescs
-rw-------  1 debian-tor adm    23655 Sep 28 14:36 cached-microdescs.new
-rw-------  1 debian-tor adm       60 Sep 28 14:36 fingerprint
drwx------  2 debian-tor adm     4096 Sep 28 13:11 keys
-rw-------  1 debian-tor adm        0 Sep 28 14:36 lock
-rw-------  1 debian-tor adm     1510 Sep 28 15:27 state
$> sudo ls -la /var/run/tor
total 8
drwxr-s---  2 debian-tor debian-tor 100 Sep 29 07:50 .
drwxr-xr-x 21 root       root       700 Sep 29 07:49 ..
srw-rw----  1 debian-tor debian-tor   0 Sep 29 07:50 control
-rw-r-----  1 debian-tor debian-tor  32 Sep 29 07:50 control.authcookie
-rw-r--r--  1 debian-tor debian-tor   5 Sep 29 07:50 tor.pid

I'm attaching the short log and the more detailed debug.log. Also the init scripts tor (which must have come with the first Tor installation) and tor.MULTIPLE, which came from the commands below, are attached.

$> cd /etc/init.d
$> sudo mv tor tor.ORIG
$> sudo wget -O tor https://www.torservers.net/misc/config/initd-tor
$> sudo mv tor tor.MULTIPLE
$> sudo mv tor.ORIG tor

Thanks!
Linda

Child Tickets

Attachments (4)

log (2.0 KB) - added by linda 7 years ago.
short log file
debug.log (2.1 MB) - added by linda 7 years ago.
log file when level is DEBUG
tor (5.6 KB) - added by linda 7 years ago.
the original init file (that came with Tor 0.2.2.x?)
tor.MULTIPLE (3.9 KB) - added by linda 7 years ago.
the init file to support multiple Tor processes

Change History (37)

Changed 7 years ago by linda

Attachment: log added

short log file

Changed 7 years ago by linda

Attachment: debug.log added

log file when level is DEBUG

Changed 7 years ago by linda

Attachment: tor added

the original init file (that came with Tor 0.2.2.x?)

Changed 7 years ago by linda

Attachment: tor.MULTIPLE added

the init file to support multiple Tor processes

comment:1 Changed 7 years ago by asn

I can't reproduce this behavior with the same Ubuntu version and the Debian obfsproxy package. It might be something in your environment.

What happens if you try to run tor without the init script?
Can you try:
tor -f torrc
where tor points to your tor binary, and torrc to your torrc file?

comment:2 in reply to:  description Changed 7 years ago by arma

These probably aren't your issues, but:

Replying to linda:

SocksPort 0
RunAsDaemon 1
User debian-tor

RunAsDaemon and User are set by the deb and are redundant here: see /usr/share/tor/tor-service-defaults-torrc

ORPort 8888
Nickname sricslbridge2
ExitPolicy reject *:* # no exits allowed

ExitPolicy defaults to reject *:* when BridgeRelay is 1 (but it shouldn't hurt to say it here too).

BridgeRelay 1
ServerTransportPlugin obfs2 exec /usr/bin/obfsproxy --managed

comment:3 in reply to:  description Changed 7 years ago by arma

Replying to linda:

$> sudo chown -R debian-tor:adm /var/tor
$> sudo ls -la /var/tor

Here's a possible hint. I expect your /usr/share/tor/tor-service-defaults-torrc says

DataDirectory /var/lib/tor

So why are you messing with /var/tor? (and where did it come from anyway -- perhaps from the other init script.)

comment:4 in reply to:  1 ; Changed 7 years ago by linda

Replying to asn:

I can't reproduce this behavior with the same Ubuntu version and the Debian obfsproxy package. It might be something in your environment.

What happens if you try to run tor without the init script?
Can you try:
tor -f torrc
where tor points to your tor binary, and torrc to your torrc file?

YES! It must be the init script:

linda@vm05:~$ tor -f /etc/tor/torrc
Oct 01 07:12:50.618 [notice] Tor v0.2.3.22-rc (git-4a0c70a817797420) running on Linux.
...
Oct 01 07:12:53.000 [notice] Registered server transport 'obfs2' at '0.0.0.0:8082'
Oct 01 07:13:02.000 [notice] Bootstrapped 100%: Done.
Oct 01 07:13:02.000 [notice] Now checking whether ORPort 128.18.9.70:8888 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Oct 01 07:13:05.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
^Z
[1]+  Stopped                 tor -f /etc/tor/torrc
linda@vm05:~$ bg
[1]+ tor -f /etc/tor/torrc &
linda@vm05:~$ sudo grep Transport /var/lib/tor/state
linda@vm05:~$ sudo grep Transport /var/tor/state
TransportProxy obfs2 0.0.0.0:8082
linda@vm05:~$ ps axu | grep obfs
linda    16315  0.0  0.0  19024  1824 pts/0    S    07:12   0:00 /usr/bin/obfsproxy --managed

Hmmmm. It uses the state under /var/tor/ (with a little hack to force it using our open port 8082). When using the init script, I think it wants to write to /var/lib/tor/state, which is why I had originally changes the permissions for those files (with no luck).

I haven't done anything to the init script since installing Tor for the first time on this machine in version 0.2.2.x (I think Dec. 2011).

Maybe you can share your init script since it seems to work? (I'm not really an expert on administrating Linux/Debian/Ubuntu, so not very familiar with the workings of /etc/init.d/ and sudo service XXX start|stop)

Now I'm trying to add all the options in /usr/share/tor/tor-service-defaults-torrc to the command line to see if it reproduces the error. It works if I leave out User debian-tor:

linda@vm05:~$ more /usr/share/tor/tor-service-defaults-torrc 
DataDirectory /var/lib/tor
PidFile /var/run/tor/tor.pid
RunAsDaemon 1
User debian-tor

ControlSocket /var/run/tor/control
ControlSocketsGroupWritable 1

CookieAuthentication 1
CookieAuthFileGroupReadable 1
CookieAuthFile /var/run/tor/control.authcookie

Log notice file /var/log/tor/log
linda@vm05:~$ sudo -u debian-tor tor -f /etc/tor/torrc DataDirectory /var/lib/tor RunAsDaemon 1 Log "notice file /var/log/tor/log" ControlSocket /var/run/tor/control ControlSocketsGroupWritable 1 PidFile /var/run/tor/tor.pid CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie
Oct 01 07:44:16.272 [notice] Tor v0.2.3.22-rc (git-4a0c70a817797420) running on Linux.
Oct 01 07:44:16.272 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Oct 01 07:44:16.272 [notice] Read configuration file "/etc/tor/torrc".
Oct 01 07:44:16.274 [notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.
Oct 01 07:44:16.274 [notice] We were compiled with headers from version 2.0.16-stable of Libevent, but we're using a Libevent library that says it's version 2.0.19-stable.
Oct 01 07:44:16.275 [notice] Initialized libevent version 2.0.19-stable using method epoll (with changelist). Good.
Oct 01 07:44:16.275 [notice] Opening Control listener on /var/run/tor/control
Oct 01 07:44:16.275 [notice] Opening OR listener on 0.0.0.0:8888
linda@vm05:~$ sudo grep obfs /var/log/tor/log
Oct 01 07:44:19.000 [notice] Registered server transport 'obfs2' at '0.0.0.0:53224'
linda@vm05:~$ sudo grep Transport /var/lib/tor/state
TransportProxy obfs2 0.0.0.0:53224

However, if I add the user as an option, tor doesn't even come up. Nothing else gets printed into /var/log/tor/log:

linda@vm05:~$ sudo -u debian-tor tor -f /etc/tor/torrc DataDirectory /var/lib/tor RunAsDaemon 1 Log "notice file /var/log/tor/log" ControlSocket /var/run/tor/control ControlSocketsGroupWritable 1 PidFile /var/run/tor/tor.pid CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie User debian-tor
Oct 01 07:47:37.331 [notice] Tor v0.2.3.22-rc (git-4a0c70a817797420) running on Linux.
Oct 01 07:47:37.331 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Oct 01 07:47:37.331 [notice] Read configuration file "/etc/tor/torrc".
Oct 01 07:47:37.334 [notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.
Oct 01 07:47:37.334 [notice] We were compiled with headers from version 2.0.16-stable of Libevent, but we're using a Libevent library that says it's version 2.0.19-stable.
Oct 01 07:47:37.334 [notice] Initialized libevent version 2.0.19-stable using method epoll (with changelist). Good.
Oct 01 07:47:37.335 [notice] Opening Control listener on /var/run/tor/control
Oct 01 07:47:37.335 [notice] Opening OR listener on 0.0.0.0:8888
Oct 01 07:47:37.335 [warn] Error setting groups to gid 115: "Operation not permitted".
Oct 01 07:47:37.335 [warn] Tor is already running as debian-tor.  You do not need the "User" option if you are already running as the user you want to be.  (If you did not set the User option in your torrc, check whether it was specified on the command line by a startup script.)
Oct 01 07:47:37.335 [warn] Failed to parse/validate config: Problem with User value. See logs for details.
Oct 01 07:47:37.335 [err] Reading config failed--see warnings above.

Does this give you any clues?

Thanks!
Linda

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

Replying to linda:

Now I'm trying to add all the options in /usr/share/tor/tor-service-defaults-torrc to the command line to see if it reproduces the error. It works if I leave out User debian-tor:

linda@vm05:~$ sudo -u debian-tor tor -f /etc/tor/torrc DataDirectory /var/lib/tor RunAsDaemon 1 Log "notice file /var/log/tor/log" ControlSocket /var/run/tor/control ControlSocketsGroupWritable 1 PidFile /var/run/tor/tor.pid CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie User debian-tor
Oct 01 07:47:37.335 [warn] Error setting groups to gid 115: "Operation not permitted".
Oct 01 07:47:37.335 [warn] Tor is already running as debian-tor. You do not need the "User" option if you are already running as the user you want to be. (If you did not set the User option in your torrc, check whether it was specified on the command line by a startup script.)
Oct 01 07:47:37.335 [warn] Failed to parse/validate config: Problem with User value. See logs for details.

Does this give you any clues?

The init script starts Tor as root, and then Tor drops privs to the debian-tor user. If you start Tor as debian-tor, you shouldn't ask it to change user. Hopefully the above explanation by Tor makes sense?

comment:6 in reply to:  5 Changed 7 years ago by linda

Replying to arma:

Replying to linda:

Now I'm trying to add all the options in /usr/share/tor/tor-service-defaults-torrc to the command line to see if it reproduces the error. It works if I leave out User debian-tor:

linda@vm05:~$ sudo -u debian-tor tor -f /etc/tor/torrc DataDirectory /var/lib/tor RunAsDaemon 1 Log "notice file /var/log/tor/log" ControlSocket /var/run/tor/control ControlSocketsGroupWritable 1 PidFile /var/run/tor/tor.pid CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie User debian-tor
Oct 01 07:47:37.335 [warn] Error setting groups to gid 115: "Operation not permitted".
Oct 01 07:47:37.335 [warn] Tor is already running as debian-tor. You do not need the "User" option if you are already running as the user you want to be. (If you did not set the User option in your torrc, check whether it was specified on the command line by a startup script.)
Oct 01 07:47:37.335 [warn] Failed to parse/validate config: Problem with User value. See logs for details.

Does this give you any clues?

The init script starts Tor as root, and then Tor drops privs to the debian-tor user. If you start Tor as debian-tor, you shouldn't ask it to change user. Hopefully the above explanation by Tor makes sense?

Yes, it does. And from the log output, I understood that calling tor from the command line as user debian-tor made the option User moot. I was just trying to get as close as possible to what the (broken?) init script does. Unfortunately, it worked like a charm when I called tor from the command line with all the other options.

I wish there was a way to see what kind of permission is denied when I use the init script. Is it writing to a file? Which one? I guess the --managed is still a mystery to me... (although I like how it works when I send SIGTERM to tor and it also kills the obfsproxy process if running).

comment:7 in reply to:  1 Changed 7 years ago by linda

Replying to asn:

I can't reproduce this behavior with the same Ubuntu version and the Debian obfsproxy package. It might be something in your environment.

What happens if you try to run tor without the init script?
Can you try:
tor -f torrc
where tor points to your tor binary, and torrc to your torrc file?

OK, another thing that works is:

$> sudo tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc
...
$> ps axu | grep tor
107      17474  0.8  1.7 396556 69412 ?        Sl   08:50   0:02 tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc
$> id debian-tor
uid=107(debian-tor) gid=115(debian-tor) groups=115(debian-tor)
$> sudo grep obfs /var/log/tor/log
Oct 01 08:50:34.000 [notice] Registered server transport 'obfs2' at '0.0.0.0:8082'
$> sudo grep Transport /var/lib/tor/state
TransportProxy obfs2 0.0.0.0:8082

but the init script still doesn't work. However, I can use the init script to stop the above started tor and obfsproxy. So using this method for now to have the bridge up and running. However, if you have any clues as to what the init script does differently to the above command line, maybe we can fix it for future use...

comment:8 Changed 7 years ago by arma

Are you certain you didn't modify the init script during all your mucking with alternate init scripts?

comment:9 Changed 7 years ago by arma

I would guess that whatever introduced /var/tor/ is what is causing the rest of your problems.

comment:10 in reply to:  8 ; Changed 7 years ago by linda

Replying to arma:

Are you certain you didn't modify the init script during all your mucking with alternate init scripts?

Not 100% certain... Where could I get a clean init script?

comment:11 Changed 7 years ago by asn

Replying to linda:

Replying to arma:

Replying to linda:

Now I'm trying to add all the options in /usr/share/tor/tor-service-defaults-torrc to the command line to see if it reproduces the error. It works if I leave out User debian-tor:

linda@vm05:~$ sudo -u debian-tor tor -f /etc/tor/torrc DataDirectory /var/lib/tor RunAsDaemon 1 Log "notice file /var/log/tor/log" ControlSocket /var/run/tor/control ControlSocketsGroupWritable 1 PidFile /var/run/tor/tor.pid CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie User debian-tor
Oct 01 07:47:37.335 [warn] Error setting groups to gid 115: "Operation not permitted".
Oct 01 07:47:37.335 [warn] Tor is already running as debian-tor. You do not need the "User" option if you are already running as the user you want to be. (If you did not set the User option in your torrc, check whether it was specified on the command line by a startup script.)
Oct 01 07:47:37.335 [warn] Failed to parse/validate config: Problem with User value. See logs for details.

Does this give you any clues?

The init script starts Tor as root, and then Tor drops privs to the debian-tor user. If you start Tor as debian-tor, you shouldn't ask it to change user. Hopefully the above explanation by Tor makes sense?

Yes, it does. And from the log output, I understood that calling tor from the command line as user debian-tor made the option User moot. I was just trying to get as close as possible to what the (broken?) init script does. Unfortunately, it worked like a charm when I called tor from the command line with all the other options.

I wish there was a way to see what kind of permission is denied when I use the init script. Is it writing to a file? Which one? I guess the --managed is still a mystery to me... (although I like how it works when I send SIGTERM to tor and it also kills the obfsproxy process if running).

The permission error happened when Tor tried to execute the file /usr/bin/obfsproxy.
execve() (the function used to execute that file) says "Permission denied" when the following things happen:

       EACCES Search permission is denied on a component of the path prefix of filename or the name of a script interpreter.  (See also path_resolution(7).)

       EACCES The file or a script interpreter is not a regular file.

       EACCES Execute permission is denied for the file or a script or ELF interpreter.

       EACCES The file system is mounted noexec.

I'm not sure in which case you belong, and unfortunately there is no way for execve() to be more verbose.

I also tried using your /etc/tor/torrc with the default init script of tor in Ubuntu, and obfsproxy spawned fine.

If you feel playful, you can move the obfsproxy binary to a different place (like /tmp/obfsproxy or something) and see if you still get the Permission Denied error. Or you can replace /usr/bin/obfsproxy with a different binary and see if you still get the same error.

comment:12 in reply to:  10 Changed 7 years ago by arma

Replying to linda:

Replying to arma:

Are you certain you didn't modify the init script during all your mucking with alternate init scripts?

Not 100% certain... Where could I get a clean init script?

apt-get purge tor (then check to make sure the init script is gone) then apt-get install tor?

Be sure to back up your torrc and whatever else you want before doing.

comment:13 Changed 7 years ago by arma

In between purge and install, you might want to blow away /var/lib/tor, /var/tor/, etc too.

comment:14 Changed 7 years ago by Christian

@Linda, I think I have the same issue here:

When I start tor via the initscript, I get the same error:

  Could not launch managed proxy executable at '/usr/bin/obfsproxy' ('Permission denied')

When I start tor manually via the commandline, it works. I too am using Ubuntu 12.04.1 LTS and in the system log I just found:

type=1400 audit(1352141151.479:26): apparmor="DENIED" operation="exec" parent=21625 profile="system_tor" \
name="/usr/bin/obfsproxy" pid=21628 comm="tor" requested_mask="x" denied_mask="x" fsuid=106 ouid=0

So it's AppArmor playing games here and somehow we must alter the policy to allow obfsproxy be started by the init-script. I'm not AppArmor savvy (yet), but that's the way to go, I suppose. Maybe you see these AppArmor messages too in your logs?

comment:15 Changed 7 years ago by cypherpunks

This is because of the apparmor profile 'system_tor' that replaces old usr.sbin.tor and that has effect only over tor loaded as a system service.

IMHO the best thing to do here is to add a line to allow tor execing obfsproxy in the file /etc/apparmor.d/local/system_tor.

/path_to_obfsproxy/obfsproxy rx

comment:16 Changed 7 years ago by Christian

Thanks! I've come accross an AppArmor profile, but this did not work. The line above did almost work, but AppArmor complained:

AppArmor parser error for /etc/apparmor.d/system_tor in /etc/apparmor.d/local/system_tor at line 4: \
 Invalid mode, 'x' must be preceded by exec qualifier 'i', 'p', 'c', or 'u'

So I replaced "rx" ("read", "execute") with "ix" ("inherit execute"):

$ cat /etc/apparmor.d/local/system_tor
        /usr/bin/obfsproxy ix,

$ apparmor_parser --version
AppArmor parser version 2.7.102
Copyright (C) 1999-2008 Novell Inc.
Copyright 2009-2012 Canonical Ltd.

Now tor can be started with the init script again and obfsproxy is started too. Yay! :)

comment:17 in reply to:  14 Changed 7 years ago by arma

Replying to Christian:

So it's AppArmor playing games here and somehow we must alter the policy to allow obfsproxy be started by the init-script.

Christian, is the apparmor profile enabled by default for your Ubuntu Tor? Or is that something you opted to do yourself?

Linda, when you fixed your other issues, did you experience this apparmor issue?

comment:18 Changed 7 years ago by Christian

AFAICS is AppArmor enabled by default in Ubuntu (I'm using a Tor-enabled Amazon-EC2 image):

$ grep APPARMOR /boot/config-3.2.0-34-virtual
CONFIG_SECURITY_APPARMOR=y
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
CONFIG_DEFAULT_SECURITY_APPARMOR=y

and /etc/apparmor.d/local/system_tor did exist, but was empty. After adding the line above to this file, Tor could be started via the init-script. The tor package (0.2.3.25-1~precise+1 from deb.torproject.org) already shipped /etc/apparmor.d/system_tor.

comment:19 Changed 6 years ago by Christian

With obfsproxy-0.2.1-2~precise+1 from http://deb.torproject.org, we have an AppArmor issue again:

[warn] Our communication channel with the managed proxy '/usr/bin/obfsproxy' closed. Most probably application stopped running.

And the syslog has:

type=1400 audit(1366160396.398:13): apparmor="DENIED" operation="open" parent=21994 profile="system_tor" name="/usr/include/python2.7/pyconfig.h" pid=21996 comm="obfsproxy" requested_mask="r" denied_mask="r" fsuid=106 ouid=0

My /etc/apparmor.d/local/system_tor already has:

/usr/bin/obfsproxy ix,

With the new denied message above, I tried to extend this as:

        /usr/bin/obfsproxy ix,
        /usr/include/python2.7/pyconfig.h ixr,

But now even more messages are spewed out:

type=1400 audit(1366169189.559:36): apparmor="DENIED" operation="open" parent=31676 profile="system_tor" name="/usr/local/lib/python2.7/dist-packages/" pid=31680 comm="obfsproxy" requested_mask="r" denied_mask="r" fsuid=106 ouid=0

type=1400 audit(1366169189.559:37): apparmor="DENIED" operation="open" parent=31676 profile="system_tor" name="/usr/share/pyshared/zope.interface-3.6.1-nspkg.pth" pid=31680 comm="obfsproxy" requested_mask="r" denied_mask="r" fsuid=106 ouid=0

type=1400 audit(1366169189.559:38): apparmor="DENIED" operation="open" parent=31676 profile="system_tor" name="/etc/python2.7/sitecustomize.py" pid=31680 comm="obfsproxy" requested_mask="r" denied_mask="r" fsuid=106 ouid=0

type=1400 audit(1366169189.559:39): apparmor="DENIED" operation="open" parent=31676 profile="system_tor" name="/usr/bin/obfsproxy" pid=31680 comm="obfsproxy" requested_mask="r" denied_mask="r" fsuid=106 ouid=0

type=1400 audit(1366169189.559:40): apparmor="DENIED" operation="open" parent=31676 profile="system_tor" name="/usr/bin/obfsproxy" pid=31680 comm="obfsproxy" requested_mask="r" denied_mask="r" fsuid=106 ouid=0

I'll have to read up on AppArmor 101 and find out how to continue from here...

comment:20 Changed 6 years ago by asn

Hm, I don't know much about AppArmor configuration, but it seems that you should allow it to access Python modules (and weird scripts like sitecustomize.py). There is probably a standard way to whitelist Python applications in AppArmor, right?

comment:21 Changed 6 years ago by cypherpunks

You can run aa-genprof which will put apparmor in complain mode then will analyze kernel logs looking for apparmor syslog messages and finally generate a more or less accurate profile for the specific program

sudo aa-genprof /usr/bin/obfsproxy

comment:22 Changed 6 years ago by Christian

Hm, this does generate a new policy in /etc/apparmor.d/usr.bin.obfsproxy (which did not exist before):

#include <tunables/global>
/usr/bin/obfsproxy {
  #include <abstractions/base>
  #include <abstractions/python>
  /usr/bin/obfsproxy r,
  /usr/bin/python2.7 ix,
}

And I still have my local/system_tor in place (which is included by /etc/apparmor.d):

        /usr/bin/obfsproxy ix,

Reload all profiles:

$ service apparmor reload

But obfsproxy is denied access again:

type=1400 audit(1366247818.957:57): apparmor="DENIED" operation="open" parent=28250 profile="system_tor" name="/usr/include/python2.7/pyconfig.h" pid=28252 comm="obfsproxy" requested_mask="r" denied_mask="r" fsuid=106 ouid=0

Interestingly it says "profile=system_tor", although I just generated /etc/apparmor.d/usr.bin.obfsproxy. Hm, for now I'll let obfsproxy run unconfined:

  /usr/bin/obfsproxy Uxr,

I'll have to ponder this a bit more. But maybe I should take this to the mailing list instead of spamming this ticket, sorry for this.

comment:23 Changed 6 years ago by funkstar

Bump. This is still an issue using nightly Tor, nightly obfsproxy with Ubuntu 13.10.

The apparmor profile needs to be fixed. What can I change to allow it to run?

comment:24 in reply to:  23 Changed 6 years ago by asn

Resolution: wontfix
Status: newclosed

Replying to funkstar:

Bump. This is still an issue using nightly Tor, nightly obfsproxy with Ubuntu 13.10.

The apparmor profile needs to be fixed. What can I change to allow it to run?

Hey funkstar,

this ticket is about the old C-based obfsproxy. obfsproxy has been reimplemented in Python since then.
See the installation instructions in https://www.torproject.org/projects/obfsproxy.html.en .

I will close this ticket as it's outdated. Please reopen if you don't think so.

comment:25 Changed 6 years ago by funkstar

Resolution: wontfix
Status: closedreopened
Version: Tor: 0.2.3.22-rcTor: 0.2.5.1-alpha

It doesn't make a difference what it's coded in. This is a permissions issue when auto launching at startup which starts with the "debian-t" profile.

Launching it via terminal there is no issues, but that launches as root. I don't know enough about apparmor to help debug it, but looking through the profiles, there are 0 entries for obfsproxy, making me think the profile was created before obfsproxy even existed.

comment:26 Changed 6 years ago by intrigeri

AFAIK, the Tor AppArmor profile is neither shipped in Tor nor obfsproxy tarballs. It is only shipped by the tor Debian package. So, the relevant place to report this bug is the Debian bug tracker.

Assuming this is done (and hopefully the problem is summarized, so that I can avoid reading 1.5 years of comments on this ticket), I've got great news for you: luckily, the person who wrote this profile, had it integrated into the Debian package, and is happy to maintain it (hint: that's me) is subscribed to the bugs affecting the tor package on the Debian bug tracker, and will then know about it... as opposed to learning about the problem 17 months after it has been submitted here.

Thanks in advance :)

comment:27 Changed 6 years ago by funkstar

I'm not using anything from Debian. I'm using the auto generated nightly PPA which is hosted on torproject.org and thus, created a ticket on the Tor ticket tracker. I will not be registering to the Debian tracker to report something that is already documented here, sorry.

The full error is below, feel free to ask any other questions, though I'm not sure what more can be said that I haven't already. There's no real need to read the other posts.

[warn] Could not launch managed proxy executable at '/usr/bin/obfsproxy' ('Permission denied')

comment:28 Changed 6 years ago by intrigeri

Reported as Debian bug 739279, with a patch attached.

Dear obfsproxy / Tor folks, I assume this is another occurrence of unclear scopes of responsibilities, that lead us to wait that long before the person responsible for these bits was made aware of the situation. In the future, please forward issues with the AppArmor profile shipped in the tor Debian package to me, or, even better, to the Debian bug tracker. Thanks in advance :)

Now, I'll let you handle this ticket the way you want, and won't monitor it.

comment:29 Changed 6 years ago by funkstar

I still don't understand what it has to do with Debian, but thank you anyway.

If they fix that, will it be pulled into the Tor PPA?

comment:30 Changed 6 years ago by funkstar

Even though you included a patch, it seems like your report has been ignored on the Debian bug tracker. :/

comment:31 in reply to:  30 Changed 6 years ago by intrigeri

Replying to funkstar:

Even though you included a patch, it seems like your report has been ignored on the Debian bug tracker. :/

Feel free to ping the maintainer (weasel) about it. Reporting that the attached patch fixes the problem for you might help.

comment:32 Changed 6 years ago by arma

Cc: weasel added

For completeness, here's the URL to the Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739279

comment:33 Changed 5 years ago by funkstar

Resolution: fixed
Status: reopenedclosed

Fixed upstream.

Note: See TracTickets for help on using tickets.