[pkg-apparmor] Bug#962530: Tor service won't start when apparmor is active and "/" is on an overlayfs

[Stefan Baur]

Am 16.06.20 um 14:48 schrieb intrigeri:

> So, I have a question:
> 
>> 4. run the following commands:
>>    apt update
>>    apt install apparmor -y
>>    service apparmor start
> 
> Did the apparmor service start before you started it manually?
> I suppose it did not start, hence the need to start it manually,
> right?

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.


[...]
> Tails' customization that makes it work with overlayfs
> lives in files that should be linked from:
> https://tails.boum.org/contribute/design/application_isolation/

Thanks for the pointer.


>> 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.
> 
> I'm reassigning to apparmor: if apparmor.service starts automatically
> in a Debian Live environment, that's a bug in that service.

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

-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243