Unix domain socket path restriction

[valoq]

While playing around with restricted unix domain sockets, I noticed that it seems impossible to restrict access to specific socket files in apparmor.
As long as the base abstraction that allows the use of unix domain sockets is included, access to all sockets in the filesystem appears to be allowed.
This seems quite strange and there are even abstractions such as for wayland that explicitly whitelist their socket files in $XDG_RUNTIME_DIR

Is this actually intended or am I overlooking something? I could not find any documentation about this, so if anyone can point out more details on this, I would appreciate that.

[valoq]

Ok, I figured out some things:

First the stupid stuff that made finding the issue real hard:

My test profile included the following line:
#include <abstractions/base>
This was supposed to be commented out.
But it turns out that #include <abstractions/base> is interpreted as include <abstractions/base>
The single # is ignored for includes, which seems quite weird. Is this an apparmor bug?

This is the test profile to reproduce the issue:
Tested on Arch, Debian Bookworm and Debian Trixie with Linux kernel from 6.1 to 6.15

abi <abi/4.0>,

profile myshell /usr/local/bin/myshell {

  /usr/local/bin/myshell mr,

  # the following are added for easier testing and would be part of an attackers payload 
  /usr/bin/swaymsg rix,
  /usr/bin/systemd-run rix,
  /usr/bin/socat1      rix,
  /usr/bin/touch       rix,
  /usr/bin/ls          rix,
  /usr/bin/nc          rix,

  /usr/lib/** rm,
  /lib/** rm,

  # has no effect on socket files
  deny /run/** rw,

  # added to avoid including abstractions for readability
  /usr/share/terminfo/a/alacritty r,
  /etc/bash.bashrc ra,
  /etc/inputrc r,
  /etc/nsswitch.conf r,
  /etc/passwd r,
  owner @{HOME}/.bash_history rw,

}

Since the base abstraction includes the permissions for sockets, it is included everywhere.

When removing the ineffectively commented include, sockets are no longer accessible

However, socket files are not treated as files by apparmor for some reason, so all sockets can be accessed (for example with ls) even when sockets are entirely excluded.
Which also means that every single profile that is allowed to use sockets, can escape the apparmor confinement as long as there are IPC sockets available somewhere in the filesystem, which is the case on all common desktop systems. So from the looks of it, there is no effective isolation on desktops with apparmor at the moment.

If I understand it correctly, there is an upcoming apparmor feature available starting in linux 6.17 that would allow to specify sockets by path and type. https://www.phoronix.com/news/Linux-6.17-AppArmor
This may be whats needed to address this issue, but unless I am overlooking something, all kernels before that wont allow effective isolation of desktop applications with apparmor since allowing sockets means allowing all sockets.
Is this a known intended behavior or a bug? I could reproduce it on debian bookworm with kernel 6.1, debian trixie and arch up to kernel 6.15

Update:
I tested this on Ubuntu 22.04 and 25.04 as well and both systems appear to isolate file path for socket communication. Since the patches that just made it into kernel 6.17 have been back ported from ubuntu, that is likely the relevant change to address this issue?
That means the only linux distribution where apparmor provides effective process isolation at the moment is ubuntu (and possible derivates).

[valoq]

After bringing this up on the apparmor mailing list, I can confirm this is indeed the current state of the upstream kernel.
As a consequence all isolation by apparmor that includes the base abstraction (or otherwise permits the use of unix domain sockets) allows for trivial sandbox escape unless a kernel with the full apparmor patches is used, like it is the case on ubuntu.

@roddhjav I suggest that we add a warning to the project page to inform users about the kernel requirement since distros like Debian or Arch are currently affected by this without any information on their wikis either.

[valoq]

Unix socket path restriction requires kernel version >= 6.17