As stated in the subject: The tor service won't start when apparmor is
active and the root filesystem is stored on an overlayfs.

Steps to reproduce:

1. Download the current "standard" Debian 10 live iso for amd64 (at the
   time of writing, this is:

<https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-10.4.0-amd64-standard.iso>)

2. Boot this image, either on real hardware or in a VM, and make sure
   you have a working internet connection for the apt update/apt install
   commands that are about to follow

3. at the "user@debian" prompt, enter "sudo -i" (you will not be
   prompted for a password)

4. run the following commands:
   apt update
   apt install apparmor -y
   service apparmor start
   apt install tor -y
   apparmor_status
   # Apparmor will show "system_tor" among the list of "enforced"
   # profiles

5. check for a running tor instance using "ps -C tor"
   Expected result: tor is running
   Actual result: tor is not running

6. try to start tor manually using "service tor start", and check for a
   running tor instance using "ps -C tor"
   Expected result: tor is running
   Actual result: tor is not running

7. run the following commands:
   apt install apparmor-utils -y
   aa-complain system_tor
   apparmor_status
   # Apparmor will show "system_tor" among the list of "complain"
   # profiles

8. try to start tor manually using "service tor start", and check for a
   running tor instance using "ps -C tor"
   Result: Only now that we switched the apparmor config from "enforce"
   to "complain", tor is able to start.

The problem seems to arise whenever an overlay file system is used for
"/" - in other words, I'm seeing this not only on Debian-Live
(combination of overlayfs and squashfs), but also in other use cases of
overlay, where only overlayfs (but not squashfs) is being used.

I believe tails (The Amnesic Incognito Live System) uses tor and
apparmor for their live cd, which, as far as I know, is Debian-based as
well, so it would be interesting to see how they solved this issue.
Maybe intrigeri (https://people.debian.org/~intrigeri / intrigeri at
debian dot org) can provide some insight?

As apparmor is causing the issue, but the corresponding "system_tor"
config file is part of the tor package, I figured I should file this
against the tor package.  Feel free to reassign the bug to the apparmor
package if bugs about broken/incomplete apparmor profiles should be
filed against that one.  The apparmor package version at the time of
writing was 2.13.2-10.

Kind Regards,
Stefan Baur

Hi,

Stefan Baur (2020-06-09):

Right, AppArmor does not play well with overlayfs out of the box.
Making that combination work requires lots of customization,
that's specific to the exact filesystem mount stack layout.

Due to that limitation, apparmor.service is supposed to *not* start in
the context of a Debian Live system. Quoting apparmor.service:

  # Don't start this unit on the Debian Live CD when using overlayfs
  ConditionPathExists=!/run/live/overlay/work

So, I have a question:

Did the apparmor service start before you started it manually?
I suppose it did not start, hence the need to start it manually,
right?

Sure. Tails' customization that makes it work with overlayfs
lives in files that should be linked from:
https://tails.boum.org/contribute/design/application_isolation/
in a Debian Live environment, that's a bug in that service.

Cheers!

Am 16.06.20 um 14:48 schrieb intrigeri:

That is correct. I ran into this issue on a system that isn't a classic
Debian Live system, but is using overlayfs (to minimize actual file
system writes on a type of flash media that doesn't have wear leveling).

I was looking for an easy way for the maintainer/triager to replicate my
issue, so instead of providing the steps needed to recreate my
particular environment, my choice fell on Debian Live.


[...]

Thanks for the pointer.

Well, no, it doesn't start automatically in a Debian Live environment,
but it does start automatically in a pretty much regular Debian
environment that does use overlayfs for the root file system.

So if it's hard to get apparmor and overlayfs to play along nicely,
maybe the check shouldn't be for a Debian Live environment but more
generally for an environment that has its root file system mounted via
overlayfs?  To avoid breaking existing installs of that kind, it should
probably print a warning to syslog instead of disabling apparmor completely.

I found that for me, adding

   /upper/var/lib/tor/** r,

underneath

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

allows me to start tor.  I haven't tried if

 /var/lib/tor/** r,

can/should be removed or needs to stay in that case. Someone more
experienced with apparmor than me should have a look at that, I think.

Note that "/upper" is not the path I'm using during the overlayfs mount,
the mountpoint actually looks like this:
overlay on / type overlay
(rw,relatime,lowerdir=/overlay/root-ro,upperdir=/overlay/root-rw/upper,workdir=/overlay/root-rw/work)

So maybe a generic fix (or a hint at how to fix it) is possible?

On apparmor install/startup, check for an overlay mount, and if it is
present, warn the user that they may need to change/add paths in their
apparmor profiles?

For extra fancyness, you could try to parse the

upperdir=/overlay/root-rw/upper

string and add "you may need to prefix /${upperdir##*/} to paths" or
something like that to the syslog message.

Kind Regards,
Stefan Baur

Hi,

Sorry for the delay!

Stefan Baur (2020-06-16):

The general problem at hand is not specific to Debian, so I encourage
folks who would like to work on this to discuss it on the upstream
AppArmor mailing list: who knows, perhaps another distro has
a solution already :)

Cheers!