Apparmor and kernel 4.14.18-1 creates tons of kern.log pop ups.


We keep trying…


Merged. Tested. Works for me.

Awesome. Thanks! :slight_smile:


Nice to hear. :slightly_smiling_face:

The various AppaArmor docs are not quite clear on the subject, but although I’m blinded, perhaps the issues in Tor Browser are fixed with the latest commits.

@torjunkie, could you merge and test?

I did not try to fix that one. Shoud be easy if it persists.


Tor Browser profile

In the Tor Browser profile on github, this text below is listed twice - not necessary I think:

Added 20/12/2017
deny @{PROC}/[0-9]/net/route r,
deny @{PROC}/[0-9]
/net/arp r,
/dev/ r,
/dev/shm/org.chromium.* rwk,

Anyway, the updated Tor Browser profile seems to have solved all the other denied msgs I outlined further above for the whonix-ws AppVM. You’re a genius :slight_smile:

Doesn’t persist.

Whonixcheck profile

But the whonixcheck updated profile doesn’t work for me. Maybe these steps are wrong below? Please point out my mistake if so:

1. For whonixcheck, open Konsole in whonix-gw TemplateVM

2. Run:

sudo rm /etc/apparmor.d/usr.bin.whonixcheck

sudo nano /etc/apparmor.d/usr.bin.whonixcheck

3. Cut and paste the following text from here:


4. Exit and save.

5. Repeat all steps above in whonix-ws TemplateVM

Restart sys-whonix and whonix-ws AppVMs

Annoying “signal rtm±93” denied messages should have disappeared. But they haven’t in either sys-whonix or whonix-ws.

Note, the only additional software I’ve ever installed is Firejail in whonix-ws-TemplateVM. I also run Tor Browser in a Firejail sandbox in combination with AppArmor. Possibly related since Patrick’s problem is solved?


Old link.


Deprecated in Whonix 13 - because merged into package - AppArmor profile for whonixcheck

Just now deleted.


Web view.


Always get it from raw (by clicking the raw button). Otherwise formatting might break or unwanted content (such as line numbers) might be copied which would then break it.


Make sure it does not have any weird content. Use a diff viewer. And/or get it using git and doing git commit gpg verification.


This solved my issues. Thanks for your hard work! Donation incoming.


Great, works! Thank you all. You can mark this as resolved since 3 users now report it’s all good.

I updated the AppArmor page to reflect how to fix AppArmor problems in general, imitating the method outlined above. Also mentioned importance of using “raw” text from github.




Getting this intermittently in anon-whonix VM after upgrade to Qubes 4-rc5. Adding raw Github profile to Ws-Template seemed to fix most of the popups but these still persist.

uname -r 4.14.18-1.pvops.qubes.x86_64
Whonix repo: Stable Proposed

audit: type=XXX audit(XXXXXXXXXX.XXX:XX): apparmor=“DENIED” operation=“signal” profile="/home//tor-browser*/Browser/firefox" pid=XXXX comm=“ProcessHangMoni” requested_mask=“send” denied_mask=“send” signal=vtalrm peer="/home//tor-browser*/Browser/firefox"

audit: type=XXXX audit(XXXXXXXXXX.XXX:XX): apparmor=“DENIED” operation=“ptrace” profile="/home/**/tor-browser*/Browser/firefox" pid=XXX comm=“ps” requested_mask=“tracedby” denied_mask=“tracedby” peer="/usr/bin/whonixcheck"


This is most likely happening when whonixcheck runs while TB is open. I could not reproduce it.

The profile is updated, blind folded as usual in this thread.

Could you check, running whonixcheck.


Confirmed. Thanks troubadour!


AppArmor and cupsd denied messages (Qubes)

Seeing this on shutting down anon-whonix (Qubes R3.2, 4.14.18-1.pvops.qubes.x86_64):

[XXXX.XXXXXX] audit: type=1400 audit (XXXXXXXXXX.XXX:XX): apparmor=“DENIED” operation=“signal” profile="/usr/sbin/cupsd" pid=1 comm=“systemd-shutdow” requested_mask=“receive” denied_mask=“receive” signal=stop peer=“unconfined”

Appears over and over. Qubes eventually shutdowns the VM anyhow.

This has not appeared recently that I remember.


Actually, sys-whonix also shows something similar on shutdown:

[XX.XXXXXXX] audit: type=1400 audit (XXXXXXXXXX.XXX:XX): apparmor=“DENIED” operation=“signal” profile="/usr/sbin/cpfpd" pid=1 com=“systemd_shutdow” requested_mask=“receive” denied_mask=“receive” signal=term peer=“unconfined”

the signal= part above also shows signal=cont OR signal=kill in different lines.


These AppArmor warnings above (x2) don’t seem to appear in Whonix 14 that I could see in logs.


This is a blocker for Whonix 14.

sudo aa-enforce /etc/apparmor.d/usr.bin.whonixcheck

ERROR: Invalid or unknown keywords in 'signal set=(rtmin+*) peer=unconfined

uname -r


Same kernel, same issue.
Should be fixed in