i2psnark Data Dir and apparmor
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) :)
Tagged: i2p, apparmor, and i2psnark