Bug#867342: tor: /usr/bin/obfs4proxy fails to load under default combination of apparmor execution permission PUx and systemd NoNewPrivileges=Yes hardening

[intrigeri]

Control: tag -1 + patch

> Care to submit a patch (with a suitable header/description) against
> the packaging?

I wanted to clean up my AppArmor plate a bit, so here we go.

Peter, I would like to fix this bug and #862993 in Stretch as well.
Happy to discuss myself with the stable release managers if the
corresponding diffs would be acceptable, whenever it helps.

Cheers,
-- 
intrigeri

>From f965fe92f38a2a2754b71b985ae1840b1425 Mon Sep 17 00:00:00 2001
From: intrigeri 
Date: Thu, 3 Aug 2017 13:21:54 +
Subject: [PATCH 1/2] AppArmor: use Pix instead of PUx for obfs4proxy (Closes:
 #867342).

For some reason, either "u" or "U" breaks obfs4proxy startup if systemd's
NoNewPrivileges is enabled. Anyway, "i" gives us a better defined confinement
than "u".
---
 debian/tor.apparmor-profile.abstraction | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/tor.apparmor-profile.abstraction b/debian/tor.apparmor-profile.abstraction
index 3324096cc..3d78c310c 100644
--- a/debian/tor.apparmor-profile.abstraction
+++ b/debian/tor.apparmor-profile.abstraction
@@ -24,4 +24,4 @@
   /usr/share/tor/** r,
 
   /usr/bin/obfsproxy PUx,
-  /usr/bin/obfs4proxy PUx,
+  /usr/bin/obfs4proxy Pix,
-- 
2.13.3

>From 88427ccad56c60b7ae36b5ed6898706c107c5f41 Mon Sep 17 00:00:00 2001
From: intrigeri 
Date: Thu, 3 Aug 2017 13:30:09 +
Subject: [PATCH 2/2] AppArmor: grant read access to
 /proc/sys/net/core/somaxconn, needed by obfs4proxy.

We did not need this previously (when obfs4proxy could start at all) as we were
running it unconfined, which is not the case anymore.
---
 debian/tor.apparmor-profile.abstraction | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/tor.apparmor-profile.abstraction b/debian/tor.apparmor-profile.abstraction
index 3d78c310c..645dc1f19 100644
--- a/debian/tor.apparmor-profile.abstraction
+++ b/debian/tor.apparmor-profile.abstraction
@@ -16,6 +16,9 @@
   /usr/bin/tor r,
   /usr/sbin/tor r,
 
+  # Needed by obfs4proxy
+  /proc/sys/net/core/somaxconn r,
+
   /proc/sys/kernel/random/uuid r,
   /sys/devices/system/cpu/ r,
   /sys/devices/system/cpu/** r,
-- 
2.13.3

Bug#867342: tor: /usr/bin/obfs4proxy fails to load under default combination of apparmor execution permission PUx and systemd NoNewPrivileges=Yes hardening

[intrigeri]

Control: tag -1 - moreinfo

Hi,

Jason J. Ayala P.:
> With tor@default.service  NoNewPrivileges=yes

> Editing abstractions/tor; reparsing with apparmor_parser -r; then restarting 
> tor@default…

> /usr/bin/obfs4proxy ...
> Pux -> Fails
> Pix -> Works
> pix -> Works

Thanks for testing. I think we should go for Pix then:

 * "P" to automatically start using a dedicated profile for obfs4proxy
   if it ever appears, and not "p" that's less safe (no environment
   variable scrubbing)

 * "i" (and not "u") because for whatever reason I don't fully get,
   either "u" or "U" triggers the breakage this bug report is about,
   and anyway "i" gives us a better defined confinement than "u"

Care to submit a patch (with a suitable header/description) against
the packaging?

Cheers,
-- 
intrigeri

Bug#867342: tor: /usr/bin/obfs4proxy fails to load under default combination of apparmor execution permission PUx and systemd NoNewPrivileges=Yes hardening

[Jason J. Ayala P.]

> Do you mean obfs4proxy (rather than obfsproxy) i.e.:

obfs4proxy, yes. 

> Do you have any AppArmor policy enabled for obfs4proxy? (use aa-status)

No aa profile for /usr/bin/obfs4proxy

With tor@default.service  NoNewPrivileges=yes

Editing abstractions/tor; reparsing with apparmor_parser -r; then restarting 
tor@default…

/usr/bin/obfs4proxy ...
Pux -> Fails
Pix -> Works
pix -> Works

Bug#867342: tor: /usr/bin/obfs4proxy fails to load under default combination of apparmor execution permission PUx and systemd NoNewPrivileges=Yes hardening

[intrigeri]

Control: tag -1 + moreinfo

Hi,

Jason J. Ayala P.:
> I was debugging why obfs4proxy was failing to load in Debian 9 (Whonix 14 
> developers), 
> without any helpful error messages in the log. I notice that if I changed the 
> AA execution
> permissions in abstractions/tor for obfsproxy to ix instead of PUx,
> it loads.

Do you mean obfs4proxy (rather than obfsproxy) i.e.:

  -  /usr/bin/obfs4proxy PUx,
  +  /usr/bin/obfs4proxy ix,

?

Do you have any AppArmor policy enabled for obfs4proxy? (use aa-status)

Please also try to see if environment variable scrubbing is involved
(with NoNewPrivileges=yes):

  -  /usr/bin/obfs4proxy PUx,
  +  /usr/bin/obfs4proxy Pux,

But don't ship that to users please.

And finally, please also try this (with NoNewPrivileges=yes):

  -  /usr/bin/obfs4proxy PUx,
  +  /usr/bin/obfs4proxy Pix,

And:

  -  /usr/bin/obfs4proxy PUx,
  +  /usr/bin/obfs4proxy pix,

Full disclosure: I've just noticed that we've been setting
NoNewPrivileges=no in Tails for a year to fix this very problem, but
apparently I totally failed at reporting this upstream back then.
Sorry! :(

Cheers,
-- 
intrigeri

Bug#867342: tor: /usr/bin/obfs4proxy fails to load under default combination of apparmor execution permission PUx and systemd NoNewPrivileges=Yes hardening

[Jason J. Ayala P.]

Package: tor
Version: 0.2.9.11-1~deb9u1
Severity: important

Dear Maintainer,

I was debugging why obfs4proxy was failing to load in Debian 9 (Whonix 14 
developers), 
without any helpful error messages in the log. I notice that if I changed the 
AA execution
permissions in abstractions/tor for obfsproxy to ix instead of PUx, it loads. I 
also
noticed that if I commented out or changed the systemd hardening flag 
NoNewPrivileges
inside systemd/system/tor@default.service, obfs4proxy also successfully loads.

I have no idea why or where to find any error message from systemd or apparmor 
about
the failure to load /usr/bin/obfs4proxy.

I also don't know how the hardening NoNewPrivileges and the apparmor execution
permission PUx interact to cause the failure to load obfs4proxy.

But changing PUx to ix AND/OR changing NoNewPrivileges to blank or YES, allows
obfs4proxy to load and tor to connect to an obfs4 bridge.

For now, I created a workaround for Whonix users that simply disables 
NoNewPrivileges.

-- System Information:
Distributor ID: Whonix
Description:Whonix GNU/Linux 9.0 (stretch)
Release:9.0
Codename:   stretch
Architecture: x86_64

Kernel: Linux 4.9.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages tor depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u1
ii  libevent-2.0-5   2.0.21-stable-3
ii  libseccomp2  2.3.1-2.1
ii  libssl1.11.1.0f-3
ii  libsystemd0  232-25
ii  lsb-base 9.20161125
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages tor recommends:
ii  logrotate3.11.0-0.1
ii  tor-geoipdb  0.2.9.11-1~deb9u1
ii  torsocks 2.2.0-1

Versions of packages tor suggests:
ii  apparmor-utils   2.11.0-3
pn  mixmaster
ii  obfs4proxy   0.0.7-1+b2
ii  obfsproxy0.2.13-2
pn  socat
ii  tor-arm  1.4.5.0-1.1
pn  torbrowser-launcher  

-- Configuration Files:
/etc/apparmor.d/abstractions/tor changed [not included]
/etc/apparmor.d/system_tor changed [not included]
/etc/default/tor changed [not included]
/etc/tor/torrc changed [not included]

-- no debconf information

-- debsums errors found:
debsums: changed file /lib/systemd/system/tor@default.service (from tor package)