You are not logged in.

#1 2019-09-19 02:34:44

Registered: 2019-09-18
Posts: 3

[Solved] Apparmor network policy support


The Apparmor network rules seem to be ignored while running stock kernel(5.2.14-arch2-1-ARCH) despite the official stated support & following the guidelines from this wiki.
The following bash script is used as a matter of validation:

$ cat /home/user/ 
echo "Hello Net World!" > hello.txt
nc 6060 -q 1 < hello.txt


$ nc -l -p 6060

is runt on my 2nd machine (just a plain Debian with netcat installed).

Then running 'aa-genprof /home/user/' to auto-generate profile prior to adding 'deny network,' manually into the newly created '/etc/apparmor.d/' which gives the following:

$ sudo cat 
# Last Modified: Wed Sep 18 20:50:53 2019
#include <tunables/global>

/home/user/ {
  #include <abstractions/base>
  #include <abstractions/bash>

  deny network,

  /dev/tty rw,
  /etc/nsswitch.conf r,
  /etc/services r,
  /home/user/ r,
  /usr/bin/bash ix,
  /usr/bin/nc mrix,
  owner /home/*/hello.txt r,


Finally followed by the expected apparmor reload & check:

$ sudo apparmor_parser -Wrv /etc/apparmor.d/
$ sudo apparmor_status 
apparmor module is loaded.
10 profiles are loaded.
10 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

The issue is that when './' is executed, the "Hello Net World!" message (& thus TCP flow) goes through the expected filtering & is printed on my 2nd machine's screen!
Testing the same sequence+profile changing distro/kernel to an openSuse or Ubuntu works/blocks well.

A few details about my system's configuration:

$ dmesg | head -n3
[    0.000000] Linux version 5.2.14-arch2-1-ARCH (builduser@heftig-683567) (gcc version 9.1.0 (GCC)) #1 SMP PREEMPT Thu Sep 12 10:42:38 UTC 2019
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=7181e1ac-63f9-4f79-bf3f-6ad1772c9748 rw apparmor=1 security=apparmor audit=1 nouveau.modeset=0 nvidia-drm.modeset=1 nvidia nvidia_modeset nvidia_uvm nvidia_drm

$ pacman -Q | grep apparmor
apparmor 2.13.3-2

$ sudo systemctl status apparmor.service 
● apparmor.service - Load AppArmor profiles
   Loaded: loaded (/usr/lib/systemd/system/apparmor.service; enabled; vendor preset: disabled)
   Active: active (exited) since Wed 2019-09-18 19:36:42 CEST; 3h 12min ago
  Process: 283 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, status=0/SUCCESS)
 Main PID: 283 (code=exited, status=0/SUCCESS)
Sep 18 19:36:41 STARQ apparmor.systemd[283]: Restarting AppArmor
Sep 18 19:36:41 STARQ apparmor.systemd[283]: Reloading AppArmor profiles
Sep 18 19:36:42 STARQ systemd[1]: Started Load AppArmor profiles.

Running these tests & doing google searches brought me mainly to an old 2012 discussion which seems to point that the kernel requires 'UBUNTU SAUCE' patching (as also told in this outdated 'linux-apparmor'  AUR ).
May someone having this 'network ruling' working shares additional details on these 'patching' steps (or whatever else that can have been missed out such as additional pkgs/configuration)?


Last edited by PatriArch (2019-10-27 19:36:03)


#2 2019-09-19 19:06:12

Registered: 2019-09-19
Posts: 1

Re: [Solved] Apparmor network policy support

I've ran some tests.. linux, linux-lts and linux-hardened official kernels from ArchLinux are all broken.

Since you mentioned Ubuntu, I downloaded and installed their most recent kernel;

[root@archws apparmor.d]# uname -a
Linux archws 5.3.0-050300-generic #201909152230 SMP Sun Sep 15 22:32:54 UTC 2019 x86_64 GNU/Linux

.. and tried the same basic ruleset:

/{usr/,}bin/ping {
    /etc/ r,
    /usr/lib/ rm,
    /usr/lib/ rm,
    /usr/lib/ rm,
    /usr/lib/ rm,
    /usr/lib/ rm,
    /usr/lib/ rm,
    /usr/lib/ rm,
    /usr/lib/ rm,

    deny network,

This should prevent ping from opening a socket, but that is not the case - ping still works fine.

[root@archws apparmor.d]# ping -c 1
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=59 time=7.86 ms

--- ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.857/7.857/7.857/0.000 ms
[root@archws apparmor.d]#

Can you please share the exact kernel version used by your Ubuntu machine that is confirmed to be working?


I also tried the latest OpenSUSE kernel, and indeed, it works fine.

[root@archws apparmor.d]# ping -c 1
ping: socket: Permission denied

Final Edit:

Okay, I figured out what's going on here - at kernel revision 4.17 release, they broke the AppArmor ABI intentionally, and as of now (5.3), network rules are never enforced on a stock kernel.
To add support again on newer kernels, you must compile your own kernel with these two patches applied beforehand: … -net.patch … mpat.patch

To compile your own own kernel, consult this excellent wiki page - to apply the patches, they must be placed in the build root directory, and they also have to be added into the source array inside your PKGBUILD.

After compiling and booting your new kernel, AppArmor network rules and auditing should now work.

[ 1817.618570] audit: type=1400 audit(1568938701.195:125): apparmor="AUDIT" operation="connect" profile="/{usr/,}bin/ping" pid=2365 comm="ping" family="inet" sock_type="dgram" protocol=17 requested_mask="connect"
[ 1817.618604] audit: type=1400 audit(1568938701.195:132): apparmor="AUDIT" operation="getsockopt" profile="/{usr/,}bin/ping" pid=2365 comm="ping" family="inet" sock_type="dgram" protocol=1 requested_mask="getopt"
[ 1817.618615] audit: type=1400 audit(1568938701.195:133): apparmor="AUDIT" operation="getattr" profile="/{usr/,}bin/ping" name="/dev/pts/0" pid=2365 comm="ping" requested_mask="r" fsuid=0 ouid=1000
[ 1817.618625] audit: type=1400 audit(1568938701.195:134): apparmor="AUDIT" operation="setsockopt" profile="/{usr/,}bin/ping" pid=2365 comm="ping" family="inet" sock_type="dgram" protocol=1 requested_mask="setopt"
[ 1817.618648] audit: type=1400 audit(1568938701.195:137): apparmor="AUDIT" operation="sendmsg" profile="/{usr/,}bin/ping" pid=2365 comm="ping" family="inet" sock_type="dgram" protocol=1 requested_mask="send"
[ 1817.618670] audit: type=1400 audit(1568938701.195:138): apparmor="AUDIT" operation="recvmsg" profile="/{usr/,}bin/ping" pid=2365 comm="ping" lport=2 family="inet" sock_type="dgram" protocol=1 requested_mask="receive"

Hope this helps - however, this is definitely an upstream issue and should be fixed in the kernel itself - in fact, it was fixed already but the commit was reverted after causing issues on some distributions..

Last edited by altoid (2019-09-20 03:12:24)


#3 2019-10-27 19:35:20

Registered: 2019-09-18
Posts: 3

Re: [Solved] Apparmor network policy support

Thank you Altoid! I've kind felt what missed but clearly, you put the green light on the right path. Much appreciated! smile
Here is a summary of the steps I've done noting there's probably a lot of better ways to achieve the whole process but since apparmor network support should be upstreamed, much polishing it would probably be kind of useless:

#-Download the patches (I've added the 2 last following-up Manjaro).

cd ~ && mkdir patch && cd patch
wget -O 0001-apparmor-fix-unnecessary-creation-of-net-compat.patch
wget -O 0002-apparmor-compatibility-with-v2.x-net.patch
wget -O 0003-apparmor-fix-use-after-free-in-sk_peer_label.patch
wget -O 0004-apparmor-fix-apparmor-mediating-locking-non-fs-unix-sockets.patch

#-Download the archlinux kernel & apply the patches to a separate branch

cd ~ && mkdir git && cd git
git clone
git checkout <base-tag> -b apparmor-branch
git apply -v <~/patch/000*>
git commit -am 'Applied apparmor patches'
git tag <kernel-ver>-apparmor

#-Perform the kernel's build & installation

cd ~ && mkdir build && cd build
asp update linux; asp checkout linux
#PKGBUILD to be updated with your git's tag "_srcver="
#PKGBUILD to be updated  "$_srcname::git+file:///home/user/git/linux/.git#tag=v$_srcver"
makepkg -s
pacman -U linux-apparmor-5.2.14.apparmor-1-x86_64.pkg.tar.xz linux-apparmor-headers-5.2.14.apparmor-1-x86_64.pkg.tar.xz
mkinitcpio -P
#"/etc/grub/default" to be updated to enable support in kernel adding "auditd=1 apparmor=1 security=apparmor" to "GRUB_CMDLINE_LINUX_DEFAULT".
grub-mkconfig -o /boot/grub./grub.cfg

A last question remains indeed: What are the problematic distributions that fail to support apparmor for network ruling? Is the issues comes from the ton of profiles sometimes provided with the default package? If so, why apparmor guys doesn't remove the profiles or at least disabled by default?


Board footer

Powered by FluxBB