On 8/11/25 02:58, valoq wrote:
On Sun, Aug 10, 2025 at 02:56:13PM -0700, John Johansen wrote:
On 8/10/25 05:25, valoq wrote:
Recently I have been testing apparmor process isolation and came across
different behaviors in regards to socket isolation, especially in regards to
socket file path filtering.
From what I have gathered, the documented features in apparmor are only
enforced with a kernel fully patched with all apparmor features, like what
ubuntu implements.
Which means that all other linux distributions out there are currently not
providing any effective process isolation through apparmor since escape path
like socket communication is wide open. (the base abstraction commonly
+included allows sockets and there is no file path filter implemented in distro
kernels other then ubuntu)
yes the base abstraction is problematic. It is something I would like to kill
but that is harder said than done
If I understand it correctly, the recently added aa patches for linux 6.17 will
bring this feature for everyone but I would like to know if this is actually
the correct assumption and if starting with kernel 6.17 the
It will for unix sockets, if you are using a version of apparmor that supports
the new abi. Because unix sockets cross both socket, and file mediation and are
done the way they are in the kernel, there was no way to land ubuntu's version
in the kernel without breaking existing policy for non-ubuntu systems. Policy
will have declare it is using the new abi, and existing unix policy rules
should work, but there are some cases where there may need to be a tweak to the
rules. The tweak is that the new unix socket is slightly stricters, when shared
across processes, so the rules are backwards compatible and will work on an
ubuntu system using the older af_unix mediation (that is it can be downgraded
transparently).
There is curently a rather popular project on github that provides many aa
profiles. https://github.com/roddhjav/apparmor.d
very aware, there is work going on to integrate most of it into the main
apparmor project. apparmor.d will continue as a fork for the bits that aren't
pulled into the upstream project.
I assume this already includes the new abi so only the kernel is missing on
most distros?
It was rather surprising to find out how different the upstream kernel handles
apparmor, especialy since there is no mention of this in any official distros
documentation. I will try to add some warning to the wikis about the kernel
requirements for effective isolation since it seems like many distros advertise
apparmor despite the trivial escape path through unix domain sockets. Thank you
for the work on bringing this into the mainline kernel
It does not, nor does Ubuntu. This side of things is a wip, it has been waiting
on the kernel to ensure there isn't any policy out there that could break, and
be used as a reason to revert the af_unix patches. It has taken a long time,
and there have been several stops and reworks along the way. Since af_unix
interacts with both network, and file the dangers of breaking someones system
with policy declaring the new abi, and yet not being updated for it is very
real. We have had kernel patches reverted for breaking userspace, because a
developer wouldn't change his abi. Which the required several cycles to rework
code, and introduce new abis etc. This has lead to several changes in the abi
system, and us being very careful about how certain features are rolled out.
Fine grained inet/inet6 mediation is still a wip, we plan to post the current
patches up for review, but it is unlikely that they will land for 6.18, those
will be more likely 6.19. Fine grained mediation of other socket types like
netlink are something for future improvement atm.
This is for filtering specific domains or network interfaces? This is not
strictly required to prevent sandbox escape though, correct?
Correct.
+upstream linux kernel actually does include all required patches to provide
effective isolation. Perhaps someone could point out where the differences
between upstream kernel and ubuntus/apparmor kernel are documented?
there is some info in the upstream wiki, the biggest issue is it hasn't been
kept up to date.
During my dive into apparmor I also noticed two possible bugs or at least
strange behaviors that I wanted to point out/have checked:
1.
If a profile has an include statement like:
include <abstractions/base>
and the profile is edited to comment out this line with a single # like this:
#include <abstractions/base>
then the single # is ignored and the include is interpreted anyway.
Only when several ## are put before the include or there is a space in between
will the line be effectively commented out. Is this intentional?
sadly yes. its a historical artifact. When includes where first added, they were add to
look like C includes (a mistake), and using the # was also considered "good" as
it allowed them to be added to policy without breaking older versions of apparmor. If you
put a space between the # and include it becomes a comment, if use double # (ie. ##) its
a comment. Its unfortunate that it still persists but there is still too much policy
using it.
It has been officially deprecated upstream, but that means its still not
removed for another 5 years
Perhaps we can get that removed
Removal will come, but it takes time. Upstream policy is once something is
deprecated it usually will take 5 years.
or at the very least create a warning in the logs about it? Took me a few hours
to figure this out and I will likely not be the only one
it already has a warning since the apparmor-3.1 release commit db246ddbb
parser: begin deprecation process for #include
you do need to make sure your warnings, aren't hiding it, which is the default
most distros use for warnings. At least if using init scripts/systemd
you can enable it through the command line with the --warn flag
$ apparmor_parser --help=warn
for deprecations
--warn=all
or
--warn=deprecated
Im not sure there is any critical use case to exploit this, but at the very
least it allows to probe for the existance of any file in the filesystem
without aa permissions and reveal its metadata, which seems to contradict
+the MAC model.
it does, and we will improve here but won't be able to do a perfect job. The
Linux kernel doesn't allow the LSM to full hide the existence of files. Its
really unfortunate, but we can certainly do better.
Doesn't the landlock lsm do exactly that? Perhaps there is a way to use the
same method in apparmor
no, it hides them the best it can, but the LSM/kernel specifically the vfs
won't let the LSM do this proper. It was objected to by the vfs maintainer back
when the LSM was trying to be merged. For the LSM hook points, and LSM can
return what it wants, but the vfs doesn't always call the LSM, eg. standard DAC
permissions are usually checked first, and if there is an error there, the vfs
will short circuit and the LSM won't get called. There are other corners where
this is the case as well. There is also the whole split between the LSM path
hooks, and the inode hooks. Where the inode hooks are called in more places but
you are missing mount information, but the path hooks aren't called everywhere
you need/would like mount information.
On an unrelated note: Has the patch for user namespace filtering made it into
the kernel yet? I havent seen any news about it recently.
it has not, all features have been backed up behind af_unix which has been
sitting in linux-next since 6.13. Each cycle, there would be something major
crop up late in the cycle making it so it wasn't ready to land. Now that
af_unix looks to have landed (fingers crossed on no reverts), we will start
pushing the remaining out of tree features. Generally 1 at a time for bigger
features (eg af_unix), and 2 or 3 at a time for smaller (userns). The goal is
to not make the PR too large, as that can result in the PR not getting accepted.
Regardless, I am very grateful and happy about the work and progress with
apparmor, so thank you.
