I was receiving a lot of messages from apparmor about i2p. This is the story of how I improved that situation …

Starting point

My systemlog was kinda full of apparmor messages. At first I didn’t understand why they said “ALLOWED” but then listed denied-flags. Turned out this is a feature called “complain mode”, in which apparmor will allow whatever, but will tell you with such a message that it would have blocked something there.

To work “some more” with apparmor, I first installed the -utils package for it:

root@anon-i2p:~# apt install apparmor-utils 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  python3-apparmor python3-libapparmor
Suggested packages:
  vim-addon-manager
The following NEW packages will be installed:
  apparmor-utils python3-apparmor python3-libapparmor
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 383 kB of archives.
After this operation, 1,137 kB of additional disk space will be used.
Do you want to continue? [Y/n] 

Looking at the status this complain-mode was listed then:

root@anon-i2p:~# aa-status
[...]
2 profiles are in complain mode.
   /usr/bin/i2prouter
   system_i2p
[...]

By switching apparmor to enforced mode for these, apparmor would start blocking all what it was now “only” complaining about. Hence I needed to find out what these message are about really …

i2psnark Data Directory

I had before provided some more disk-space to the virtual machine running this, by mounting an external directory for that (into /srv). And yes, the messages seemed to be all about this. So I attempt to allow access to this directory by doing:

root@anon-i2p:~# vim /etc/apparmor.d/system_i2p 
[...]
  include <abstractions/i2p>
[...]
  # Site-specific additions and overrides. See local/README for details.
  #include <local/system_i2p>
  owner /srv/** rwk,

Therein, the ** makes the rule recursive (i.e. for the whole sub-tree there might be) and the permission rwk allow read, write, and locking-access respectively. I’m unaware whether locking is used here, but … Also I un-commented that include line, but for that I actually don’t know what I’m doing there - just wanted to be sure the file is used I guess.

I then want rules to be enforced, so let’s switch that now:

root@anon-i2p:~# aa-enforce /etc/apparmor.d/usr.bin.i2prouter
root@anon-i2p:~# aa-enforce /etc/apparmor.d/system_i2p
root@anon-i2p:~# aa-status
apparmor module is loaded.
[...]
0 profiles are in complain mode.
[...]

I did restart apparmor and the i2p-router after this. A reload of apparmor might have done the trick, though. But while trying around with this I had blocked attempts of i2psnark before and wanted it to start with a clean slate ;)

Aftermath

After this I’m still getting a denied when starting up the router:

Jan 08 11:11:11 anon-i2p kernel: audit: type=1400 audit(timestamp): apparmor="DENIED" operation="file_mmap" profile="system_i2p" name="/usr/lib/jvm/java-11-openjdk-amd64/lib/server/classes.jsa" pid=1111 comm="java" requested_mask="m" denied_mask="m" fsuid=111 ouid=0

I’ll need to investigate whether this should concern me. Because something might not be working now, due to that, and I just haven’t noticed yet?

Aside from that it seems I achieved my goal to avoid cluttered log-files …

Fix for classes.jsa

After inquiring about it on #i2p-dev zzz suggested to basically make the existing line with classes.jsa in abstractions/i2p fit the path requested here (server/classes.jsa instead of client/classes.jsa). I do so by:

root@anon-i2p:~# vim /etc/apparmor.d/abstractions/i2p 
  # */client/classes.jsa is only found (and needed) in 32-bit JVMs.
  /usr/lib/jvm/**/classes.jsa          m,
#  /usr/lib/jvm/*/jre/lib/i386/client/classes.jsa          m,

The second should be redundant (before and after this change), so I just commented it out.

With this the i2p router starts without apparmor DENYING anything anymore. Sounds good (better) :)