fix obfs4proxy AppArmor issue in Whonix 14

phabricator-migrator · February 19, 2024, 5:43pm

Information

ID: 676
PHID: PHID-TASK-3n2avfoicpx5xavp7h73
Author: Patrick
Status at Migration Time: resolved
Priority at Migration Time: Normal

Description

It might be broken due to AppArmor profile related changes by Tor / obfs4proxy in #debian_stretch.

Changes to GitHub - Kicksecure/apparmor-profile-dist: AppArmor profile for Derivative Linux Distributions - https://www.kicksecure.com/wiki/AppArmor - for better security (hardening). might be required.

Related upstream bug report:

Comments

JasonJAyalaP

2017-06-02 23:31:45 UTC

Patrick

2017-06-03 13:19:33 UTC

JasonJAyalaP

2017-06-03 17:19:25 UTC

JasonJAyalaP

2017-06-22 00:28:54 UTC

Patrick

2017-06-22 10:09:42 UTC

JasonJAyalaP

2017-06-26 08:32:59 UTC

Patrick

2017-06-26 08:53:32 UTC

! In T676#13825, @JasonJAyalaP wrote:
Which app armor profile is blocking obfs4?

/etc/apparmor.d/system_tor

To figure this out, keep watching logs:

https://forums.whonix.org/t/whonix-14-debian-stretch-apparmor-related-changes

Something from us or an apparmor profile that comes from tpo?
dpkg -S /etc/apparmor.d/system_tor
tor: /etc/apparmor.d/system_tor

Patrick

2017-06-26 08:58:12 UTC

JasonJAyalaP

2017-06-26 09:42:23 UTC

Patrick

2017-06-26 11:37:01 UTC

JasonJAyalaP

2017-06-28 21:56:04 UTC

AA doesn’t report a denied message when tor tries to launch obfs4. However:

the line
/usr/bin/obfs4proxy PUx, 
in
/etc/apparmor.d/abstractions/tor
when changed to
/usr/bin/obfs4proxy rix, 
makes obfs4 work again. Maybe it should Ux or ix. I’m not sure. But what I really don’t know is how system_tor interacts with abstractions/

Patrick

2017-06-29 00:55:48 UTC

But what I really don’t know is how system_tor interacts with abstractions/

cat /etc/apparmor.d/system_tor
# vim:syntax=apparmor
#include <tunables/global>

profile system_tor flags=(attach_disconnected) {
  #include <abstractions/tor>

And by the way… Also does…

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

Patrick

2017-06-29 01:01:48 UTC

/etc/apparmor.d/system_tor after #include <abstractions/tor> and #include <local/system_tor> will be interpreted like the following, I think:

# vim:syntax=apparmor
#include <tunables/global>

profile system_tor flags=(attach_disconnected) {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  network tcp,
  network udp,

  capability chown,
  capability dac_override,
  capability fowner,
  capability fsetid,
  capability setgid,
  capability setuid,

  /usr/bin/tor r,
  /usr/sbin/tor r,

  /proc/sys/kernel/random/uuid r,
  /sys/devices/system/cpu/ r,
  /sys/devices/system/cpu/** r,

  /etc/tor/* r,
  /usr/share/tor/** r,

  /usr/bin/obfsproxy PUx,
  /usr/bin/obfs4proxy PUx,

  owner /var/lib/tor/** rwk,
  owner /var/lib/tor/ r,
  owner /var/log/tor/* w,

  # During startup, tor (as root) tries to open various things such as
  # directories via check_private_dir().  Let it.
  /var/lib/tor/** r,

  /{,var/}run/tor/ r,
  /{,var/}run/tor/control w,
  /{,var/}run/tor/socks w,
  /{,var/}run/tor/tor.pid w,
  /{,var/}run/tor/control.authcookie w,
  /{,var/}run/tor/control.authcookie.tmp rw,
  /{,var/}run/systemd/notify w,

  ## Anonymity Distributions
  /etc/hosts.anondist r,
  /etc/resolv.conf.anondist r,
  /run/tor r,
  /run/tor/log rwk,

## Add permissions for obfsproxy and flashproxy.
## AUDIT:
## These profile rules may be too permissive. Needs audit and someone dedicated
## to work on AppArmor profiles. It's not a serious security issue in any case,
## because AppArmor isn't enabled by default in Debian stretch yet and little
## work is being done on it at time of writing. So it's a lax AppArmor profile
## versus no AppArmor at all.

  ## obfsproxy
  /usr/local/lib/python*/** r,
  /var/log/tor/log rw,
  /dev/urandom r,
  /dev/random r,
  /usr/** r,
  /etc/python*/sitecustomize.py r,
  ## https://forums.whonix.org/t/after-last-apt-get-upgrade-gateway-doesnt-connect-to-tor-anymore
  #/usr/bin/obfsproxy rix,

  ## flashproxy
  @{HOME}/.tb/tor-browser/App/flashproxy-client rix,
  @{HOME}/.tb/tor-browser/App/flashproxy-reg-appspot rix,
  @{HOME}/.tb/tor-browser/App/flashproxy-reg-url rix,
  @{HOME}/.tb/tor-browser/App/flashproxy-reg-http rix,
  @{HOME}/.tb/tor-browser/App/flashproxy-reg-email rix,
  @{HOME}/.tb/tor-browser/App/** rm,
  /usr/bin/python* rix,
  /usr/lib/python*/dist-packages/** m,
  /usr/lib/python*/lib-dynload/** m,
  /usr/lib/pyshared/python*/OpenSSL/** m,
  /usr/lib/python*/lib-dynload/** m,
  /usr/lib/pyshared/python*/numpy/** m,
  /proc/*/mounts r,
}

JasonJAyalaP

2017-06-29 01:28:17 UTC

Ah. I didn’t see the include. Makes sense.

PUx + those obfsproxy specific rules work fine.
Changing obfs4 to rix works fine.

Questions:

Is “include abstractions/tor” normal and desirable behavour? Is that something tor does or we do? Shouldn’t all our changes be in .anondist?

I don’t fully understand apparmors execution persions (QuickProfileLanguage · Wiki · AppArmor / apparmor · GitLab). But if obfsproxy is being executed as “unconfined” (PUx), are those obfsproxy specific permissions (under AUDIT) even doing anything? They were with rix, I believe, but not currently. Actually, the P means it will look for a obfsproxy specific profile. So we certainly don’t need both.

I didn’t fully understand the problem people were getting with obfsproxy rix. I wonder if it can be fixed (or if we should just run it unconfined.

I have no clue why a more restrictive exection permission (rix) would allow tor to run obfs4proxy, but a less restrictive one (PUx) would not.

That apparmor page isn’t clear if capital PU is prefered for productive and not only development (I’m not sure what “scrub the environment” means)

Patrick

2017-06-29 12:14:42 UTC

! In T676#13872, @JasonJAyalaP wrote:
Ah. I didn’t see the include. Makes sense.

I mentioned it in T676#13830.

Is “include abstractions/tor” normal and desirable behavour?

Yes, many profiles do that.

Is that something tor does or we do?

Tor should do.

Shouldn’t all our changes be in .anondist?

Ideally, yes in local/name.anondist. Seems most appropriate where distributions should add their overrides in absence of something better.

I don’t fully understand apparmors execution persions (QuickProfileLanguage · Wiki · AppArmor / apparmor · GitLab). But if obfsproxy is being executed as “unconfined” (PUx), are those obfsproxy specific permissions (under AUDIT) even doing anything? They were with rix, I believe, but not currently. Actually, the P means it will look for a obfsproxy specific profile. So we certainly don’t need both.

I didn’t fully understand the problem people were getting with obfsproxy rix. I wonder if it can be fixed (or if we should just run it unconfined.

Running obs(4)proxy unconfined should be good enough for now until an obfs4proxy profiles is provided. We could contribute this as an enhancement later.

That apparmor page isn’t clear if capital PU is prefered for productive and not only development (I’m not sure what “scrub the environment” means)

Environment variables. Should be preferred if possible, although environment should be clean anyhow since started by systemd.

Patrick

2017-06-29 12:30:53 UTC

In this case, a /local file can probably not do the trick.

If we run unconfined, the following is probably alright to remove.
  ## obfsproxy
  /usr/local/lib/python*/** r,
  /var/log/tor/log rw,
  /dev/urandom r,
  /dev/random r,
  /usr/** r,
  /etc/python*/sitecustomize.py r,
  ## https://forums.whonix.org/t/after-last-apt-get-upgrade-gateway-doesnt-connect-to-tor-anymore
  #/usr/bin/obfsproxy rix,
Since /usr/bin/obfs4proxy PUx, is included by Debian tors /etc/apparmor.d/abstractions/tor, upstream has probably attempted to fix the apparmor profile thing. Since you don’t get any apparmor warnings, the issue is not apparmor, but systemd seccomp whitelist.

Yes. Something in /lib/systemd/system/tor@default.service is causing this.
#NoNewPrivileges=yes
#PrivateTmp=yes
#PrivateDevices=yes
#ProtectHome=yes
#ProtectSystem=full
#ReadOnlyDirectories=/
#ReadWriteDirectories=-/proc
#ReadWriteDirectories=-/var/lib/tor
#ReadWriteDirectories=-/var/log/tor
#ReadWriteDirectories=-/var/run
#CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE
Next steps. Please:

figure out which one

reproduce this on plain non-Whonix Debian

report a bug against Debian’s tor package (if there isn’t already one)

add a systemd drop-in .d file for tor’s systemd unit as our Whonix specific override (to be included in package #anon-gw-anonymizer-config)

Patrick

2017-06-29 12:34:01 UTC

To save you from somehow learning about systemd overrides the hard way…

If for example in line CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_OVERRIDE the CAP_DAC_OVERRIDE is the issue… Create a file…

/lib/systemd/system/tor@default.service.d/40_obfs4proxy-workaround.conf
[Service]
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
This could be the solution then. Just to show the general syntax of systemd override files.

JasonJAyalaP

2017-06-30 01:59:51 UTC

JasonJAyalaP

2017-06-30 01:57:26 UTC

Patrick

2017-06-30 10:44:37 UTC

Pux (already Tor’s default) is alright.

! In T676#13940, @JasonJAyalaP wrote:
Is it the nature of obfs4 to require “gaining new privileges”?

I have no idea.

If so, we have to remove this line or change the execution permissions of obfs4 in apparmor.

(btw, I haven’t been able to debug tor without apparmor. If I aa-disable the tor profile, tor fails to load.)

aa-disable does not apply to Tor’s systemd service, because it’s systemd unit file enforces apparmor independent from aa-disable / aa-enforce command line tools.

/lib/systemd/system/tor@default.service:
AppArmorProfile=system_tor

JasonJAyalaP

2017-07-01 00:42:03 UTC

Patrick

2017-07-01 09:57:23 UTC

JasonJAyalaP (Jason J. Ayala P.):

JasonJAyalaP added a comment.

Two things work:

Changing obfs4 execution permission in system_tor apparmor profile
(abstractions/tor) from PUx to ix.

Keeping PUx but removing “NoNewPrivileges” from tor@default
systemd service (/lib/systemd/system)

Please report this analysis at the Debian tracker for the tor package.
That’s the right place and the right maintainer to figure out. Debian
bug reporting policy even recommends to report bugs against Debian,
because then maintainers will contact upstream of Debian.

(Sometimes we ignore this - when Debian maintainers don’t do it, are
slow, or somehow it does not matter. For example, why should one request
a new add-on api for firefox from Debian if that can be requested at
Mozilla’s tracker. But in this case, the apparmor profile and systemd
unit file is by Debian, not by Tor Project, I think.)

Meanwhile, until upstream sorts this out, please add a systemd .d
drop-in as mentioned above as temporary workaround disabling it.
[Service]
NoNewPrivileges=
Plus with ## a short comment and a link to this ticket to justify the
change (even to ourselves if we look into it again in future).

(If that does not work: Try NoNewPrivileges=No.)

I prefer this solution, because it’s the most lightweight and least
intrusive workaround, most likely stable one as well. We can use a
drop-in and don’t need to modify any files owned by upstream/third party
packages.

Once upstream has sorted that, we need to remove our workaround.

JasonJAyalaP

2017-07-05 21:42:08 UTC

JasonJAyalaP

2017-07-05 22:25:15 UTC

Patrick

2017-07-06 12:28:30 UTC

Patrick

2017-07-06 12:35:07 UTC

Patrick

2017-09-03 12:12:27 UTC

JasonJAyalaP

2017-09-04 21:11:31 UTC

JasonJAyalaP

2017-09-04 21:29:11 UTC

with =no, I’m no longer getting the parsing error
sudo journalctl | grep workaround
but /lib/systemd/system/tor@default.service is unaffected
# Hardening
AppArmorProfile=system_tor
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
...

Patrick

2017-09-05 09:56:46 UTC

! In T676#14449, @JasonJAyalaP wrote:
with =no, I’m no longer getting the parsing error
sudo journalctl | grep workaround
but /lib/systemd/system/tor@default.service is unaffected
# Hardening
AppArmorProfile=system_tor
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
...
Expected so it is. systemctl cat tor@default (should be same as systemctl cat tor@default.service) should show it.

And does obfs4proxy actually work then?

Patrick

2017-09-05 10:04:13 UTC

JasonJAyalaP

2017-09-06 18:23:13 UTC

Ah I see.

user@host:~$ systemctl cat tor@default
# /lib/systemd/system/tor@default.service
[Unit]
Description=Anonymizing overlay network for TCP
After=network.target nss-lookup.target
PartOf=tor.service
ReloadPropagatedFrom=tor.service

[Service]
Type=notify
NotifyAccess=all
PIDFile=/var/run/tor/tor.pid
PermissionsStartOnly=yes
ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /var/run/tor
ExecStartPre=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config
ExecStart=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
ExecReload=/bin/kill -HUP ${MAINPID}
KillSignal=SIGINT
TimeoutStartSec=300
TimeoutStopSec=60
Restart=on-failure
LimitNOFILE=65536

# Hardening
AppArmorProfile=system_tor
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=-/proc
ReadWriteDirectories=-/var/lib/tor
ReadWriteDirectories=-/var/log/tor
ReadWriteDirectories=-/var/run
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_READ_SEARCH

# /lib/systemd/system/tor@default.service.d/40_obfs4proxy-workaround.conf
## The hardening option NoNewPrvileges=Yes in the Debian tor@default.service file breaks loading of obfs4proxy in combination with Debian's apparmor profile which uses PUx. (ix ex
## https://phabricator.whonix.org/T676
[Service]
NoNewPrivileges=no

Tested with bridges obfs4 from TPO. Connects.