Apparmor as Anti Malware

limotux · June 4, 2025, 4:25pm

Hi guys.
Again about security.

I tried “jail” sometime ago and it gave me hard time. It its too protective.

Now thinking about apparmor

I just have an issue, reading here and there I got confused as I got two contradicting statements. Some say it restricts what apps can do and what files can each app access or process (profiles/rules) for each app and apps without profiles (malware) can do nothing to the files. Others said it just restricts what an app can or can’t do but malware as not having a profile then apparmor has no rules to apply to malware so malware can do whatever it wants.

Which is true or I am misunderstanding the whole thing?

If it is the first then I assume no malware can do anything to my files.

If it is the second I am thinking and wondering if it is possible to create a new profile that tells apparmor to allow only apps that has profiles to access my files and stop any app that does not have a profile from even seeing my files.

I feel apparmor can somehow like immunize my files against any malware.

Am I thinking right or I am missing the whole thing.

Sorry of I am asking stupid questions but I have been reading a lot and got confused.

Here is the only place I can trust the info I get.

By the way I read on Arch wiki that

Access is denied by default if no profile says otherwise.

Does this mean that malware that does not have a profile will be denied access to the files by default?
I will highly appreciate enlightening me on what apparmor can and can’t do, especially creating this profile that simply says “if there is a profile let it do what the profile allows, if no profile let it even not see the files”.
I hope I find a way to immunize my files.
Thanks for your valuable input.

Svartis · June 4, 2025, 4:39pm

I’m no apparmor expert, but from my understanding it limits the privileges of the app itself.

If you install snap there is a test profile set to the hello-world-evil snap package, to test apparmor.

It contains the following lines:


# vim:syntax=apparmor

#include <tunables/global>


#include if exists "/var/lib/snapd/apparmor/snap-tuning"

# snapd supports the concept of 'parallel installs' where snaps with the same
# name are differentiated by '_<instance>' such that foo, foo_bar and foo_baz
# may all be installed on the system. To support this, SNAP_NAME is set to the
# name (eg, 'foo') while SNAP_INSTANCE_NAME is set to the instance name (eg
# 'foo_bar'). The profile name and most rules therefore reference
# SNAP_INSTANCE_NAME. In some cases, snapd will adjust the snap's runtime
# environment so the snap doesn't have to be aware of the distinction (eg,
# SNAP, SNAP_DATA and SNAP_COMMON are all bind mounted onto a directory with
# SNAP_NAME so the security policy will allow writing to both locations (since
# they are equivalent).

# This is a snap name without the instance key
@{SNAP_NAME}="hello-world"
# This is a snap name with instance key
@{SNAP_INSTANCE_NAME}="hello-world"
@{SNAP_INSTANCE_DESKTOP}="hello-world"
@{SNAP_COMMAND_NAME}="evil"
@{SNAP_REVISION}="29"
@{PROFILE_DBUS}="snap_2ehello_2dworld_2eevil"
@{INSTALL_DIR}="/{,var/lib/snapd/}snap"

profile "snap.hello-world.evil" flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/base>
  #include <abstractions/consoles>
  #include <abstractions/openssl>
  

  # While in later versions of the base abstraction, include this explicitly
  # for series 16 and cross-distro
  /etc/ld.so.preload r,

  # The base abstraction doesn't yet have this
  /etc/sysconfig/clock r,
  owner @{PROC}/@{pid}/maps k,

  # /proc/XXXX/map_files contains the same info than /proc/XXXX/maps, but
  # in a format that is simpler to manage, because it doesn't require to
  # parse the text data inside a file, but just reading the contents of
  # a directory.
  # Reading /proc/XXXX/maps is already allowed in the base template
  # via <abstractions/base>. Also, only the owner can read it, and the
  # kernel limits access to it by requiring 'ptrace' enabled, so allowing
  # to access /proc/XXXX/map_files can be considered secure too.
  owner @{PROC}/@{pid}/map_files/ r,

  # While the base abstraction has rules for encryptfs encrypted home and
  # private directories, it is missing rules for directory read on the toplevel
  # directory of the mount (LP: #1848919)
  owner @{HOME}/.Private/ r,
  owner @{HOMEDIRS}/.ecryptfs/*/.Private/ r,

  # for python apps/services
  #include <abstractions/python>
  /etc/python3.[0-9]*/**                                r,

  
# explicitly deny noisy denials to read-only filesystems (see LP: #1496895
# for details)
deny /usr/lib/python3*/{,**/}__pycache__/ w,
deny /usr/lib/python3*/{,**/}__pycache__/**.pyc.[0-9]* w,
# bind mount used here (see 'parallel installs', above)
deny @{INSTALL_DIR}/{@{SNAP_NAME},@{SNAP_INSTANCE_NAME}}/**/__pycache__/             w,
deny @{INSTALL_DIR}/{@{SNAP_NAME},@{SNAP_INSTANCE_NAME}}/**/__pycache__/*.pyc.[0-9]* w,


  # for perl apps/services
  #include <abstractions/perl>
  # Missing from perl abstraction
  /usr/lib/@{multiarch}/perl{,5,-base}/auto/**.so* mr,

  # Note: the following dangerous accesses should not be allowed in most
  # policy, but we cannot explicitly deny since other trusted interfaces might
  # add them.
  # Explicitly deny ptrace for now since it can be abused to break out of the
  # seccomp sandbox. https://lkml.org/lkml/2015/3/18/823
  #audit deny ptrace (trace),

  # Explicitly deny capability mknod so apps can't create devices
  #audit deny capability mknod,

  # Explicitly deny mount, remount and umount so apps can't modify things in
  # their namespace
  #audit deny mount,
  #audit deny remount,
  #audit deny umount,

  # End dangerous accesses

  # Note: this potentially allows snaps to DoS other snaps via resource
  # exhaustion but we can't sensibly mediate this today. In the future we may
  # employ cgroup limits, AppArmor rlimit mlock rules or something else.
  capability ipc_lock,

  # for bash 'binaries' (do *not* use abstractions/bash)
  # user-specific bash files
  /etc/bash.bashrc r,
  /etc/inputrc r,
  /etc/environment r,
  /etc/profile r,

  # user/group/seat lookups
  /etc/{passwd,group,nsswitch.conf} r,  # very common
  /var/lib/extrausers/{passwd,group} r,
  /run/systemd/users/[0-9]* r,
  /etc/default/nss r,

  # libnss-systemd (subset from nameservice abstraction)
  #
  #   https://systemd.io/USER_GROUP_API/
  #   https://systemd.io/USER_RECORD/
  #   https://www.freedesktop.org/software/systemd/man/nss-systemd.html
  #
  # Allow User/Group lookups via common VarLink socket APIs. Applications need
  # to either consult all of them or the io.systemd.Multiplexer frontend.
  /run/systemd/userdb/ r,
  /run/systemd/userdb/io.systemd.Multiplexer rw,
  /run/systemd/userdb/io.systemd.DynamicUser rw,        # systemd-exec users
  /run/systemd/userdb/io.systemd.Home rw,               # systemd-home dirs
  /run/systemd/userdb/io.systemd.NameServiceSwitch rw,  # UNIX/glibc NSS
  /run/systemd/userdb/io.systemd.Machine rw,            # systemd-machined

  /etc/libnl-3/{classid,pktloc} r,      # apps that use libnl

  # For snappy reexec on 4.8+ kernels
  /usr/lib/snapd/snap-exec m,

  # For gdb support
  /usr/lib/snapd/snap-gdb-shim ixr,
  /usr/lib/snapd/snap-gdbserver-shim ixr,

  # For in-snap tab completion
  /etc/bash_completion.d/{,*} r,
  /usr/lib/snapd/etelpmoc.sh ixr,               # marshaller (see complete.sh for out-of-snap unmarshal)
  /usr/share/bash-completion/bash_completion r, # user-provided completions (run in-snap) may use functions from here

  # uptime
  @{PROC}/uptime r,
  @{PROC}/loadavg r,

  # Allow reading /etc/os-release. On Ubuntu 16.04+ it is a symlink to /usr/lib
  # which is allowed by the base abstraction, but on 14.04 it is an actual file
  # so need to add it here. Also allow read locks on the file.
  /etc/os-release rk,
  /usr/lib/os-release k,

  # Debian version of the host OS which might be required in AppArmor-secured Debian
  /etc/debian_version r,

  # systemd native journal API (see sd_journal_print(4)). This should be in
  # AppArmor's base abstraction, but until it is, include here. We include
  # the base journal path as well as the journal namespace pattern path. Each
  # journal namespace for quota groups will be prefixed with 'snap-'.
  /run/systemd/journal{,.snap-*}/socket w,
  /run/systemd/journal{,.snap-*}/stdout rw, # 'r' shouldn't be needed, but journald
                                            # doesn't leak anything so allow
  /run/systemd/journal{,.snap-*}/dev-log w,

  # snapctl and its requirements
  /usr/bin/snapctl ixr,
  /usr/lib/snapd/snapctl ixr,
  @{PROC}/sys/net/core/somaxconn r,
  /run/snapd-snap.socket rw,

  # Note: for now, don't explicitly deny this noisy denial so --devmode isn't
  # broken but eventually we may conditionally deny this since it is an
  # information leak.
  #deny /{,var/}run/utmp r,

  # java
  @{PROC}/@{pid}/ r,
  @{PROC}/@{pid}/fd/ r,
  owner @{PROC}/@{pid}/auxv r,
  @{PROC}/sys/vm/zone_reclaim_mode r,
  /etc/lsb-release r,
  /sys/devices/**/read_ahead_kb r,
  /sys/devices/system/cpu/** r,
  /sys/devices/system/node/node[0-9]*/* r,
  /sys/kernel/mm/transparent_hugepage/enabled r,
  /sys/kernel/mm/transparent_hugepage/defrag r,
  # NOTE: this leaks running process but java seems to want it (even though it
  # seems to operate ok without it) and SDL apps crash without it. Allow owner
  # match until AppArmor kernel var is available to solve this properly (see
  # LP: #1546825 for details). comm is a subset of cmdline, so allow it too.
  owner @{PROC}/@{pid}/cmdline r,
  owner @{PROC}/@{pid}/comm r,

  # Per man(5) proc, the kernel enforces that a thread may only modify its comm
  # value or those in its thread group.
  owner @{PROC}/@{pid}/task/@{tid}/comm rw,

  # Allow reading and writing to our file descriptors in /proc which, for
  # example, allow access to /dev/std{in,out,err} which are all symlinks to
  # /proc/self/fd/{0,1,2} respectively. To support the open(..., O_TMPFILE)
  # linkat() temporary file technique, allow all fds. Importantly, access to
  # another task's fd via this proc interface is mediated via 'ptrace (read)'
  # (readonly) and 'ptrace (trace)' (read/write) which is denied by default, so
  # this rule by itself doesn't allow opening another snap's fds via proc.
  owner @{PROC}/@{pid}/{,task/@{tid}}fd/[0-9]* rw,

  # Miscellaneous accesses
  /dev/{,u}random w,
  /etc/machine-id r,
  /etc/mime.types r,
  /etc/default/keyboard r,
  @{PROC}/ r,
  @{PROC}/version r,
  @{PROC}/version_signature r,
  /etc/{,writable/}hostname r,
  /etc/{,writable/}localtime r,
  /etc/{,writable/}mailname r,
  /etc/{,writable/}timezone r,
  owner @{PROC}/@{pid}/cgroup rk,
  @{PROC}/@{pid}/cpuset r,
  @{PROC}/@{pid}/io r,
  owner @{PROC}/@{pid}/fdinfo/* r,
  owner @{PROC}/@{pid}/limits r,
  owner @{PROC}/@{pid}/loginuid r,
  owner @{PROC}/@{pid}/sessionid r,
  @{PROC}/@{pid}/smaps r,
  @{PROC}/@{pid}/stat r,
  @{PROC}/@{pid}/statm r,
  @{PROC}/@{pid}/status r,
  @{PROC}/@{pid}/task/ r,
  @{PROC}/@{pid}/task/[0-9]*/smaps r,
  @{PROC}/@{pid}/task/[0-9]*/stat r,
  @{PROC}/@{pid}/task/[0-9]*/statm r,
  @{PROC}/@{pid}/task/[0-9]*/status r,
  @{PROC}/sys/fs/pipe-max-size r,
  @{PROC}/sys/kernel/hostname r,
  @{PROC}/sys/kernel/osrelease r,
  @{PROC}/sys/kernel/ostype r,
  @{PROC}/sys/kernel/pid_max r,
  @{PROC}/sys/kernel/yama/ptrace_scope r,
  @{PROC}/sys/kernel/shmmax r,
  # Allow apps to introspect the level of dbus mediation AppArmor implements.
  /sys/kernel/security/apparmor/features/dbus/mask r,
  @{PROC}/sys/fs/file-max r,
  @{PROC}/sys/fs/file-nr r,
  @{PROC}/sys/fs/inotify/max_* r,
  @{PROC}/sys/kernel/pid_max r,
  @{PROC}/sys/kernel/random/boot_id r,
  @{PROC}/sys/kernel/random/entropy_avail r,
  @{PROC}/sys/kernel/random/uuid r,
  @{PROC}/sys/kernel/cap_last_cap r,
  # Allow access to the uuidd daemon (this daemon is a thin wrapper around
  # time and getrandom()/{,u}random and, when available, runs under an
  # unprivilged, dedicated user).
  /run/uuidd/request rw,
  /sys/devices/virtual/tty/{console,tty*}/active r,
  /sys/fs/cgroup/memory/{,user.slice/}memory.limit_in_bytes r,
  /sys/fs/cgroup/memory/{,**/}snap.@{SNAP_INSTANCE_NAME}{,.*}/memory.limit_in_bytes r,
  /sys/fs/cgroup/memory/{,**/}snap.@{SNAP_INSTANCE_NAME}{,.*}/memory.stat r,
  /sys/fs/cgroup/system.slice/snap.@{SNAP_INSTANCE_NAME}{,.*}/memory.max r,
  /sys/fs/cgroup/cpu,cpuacct/{,user.slice/}cpu.cfs_{period,quota}_us r,
  /sys/fs/cgroup/cpu,cpuacct/{,**/}snap.@{SNAP_INSTANCE_NAME}{,.*}/cpu.cfs_{period,quota}_us r,
  /sys/fs/cgroup/cpu,cpuacct/{,user.slice/}cpu.shares r,
  /sys/fs/cgroup/cpu,cpuacct/{,**/}snap.@{SNAP_INSTANCE_NAME}{,.*}/cpu.shares r,
  /sys/kernel/mm/transparent_hugepage/hpage_pmd_size r,
  /sys/module/apparmor/parameters/enabled r,
  /{,usr/}lib/ r,

  # Reads of oom_adj and oom_score_adj are safe
  owner @{PROC}/@{pid}/oom_{,score_}adj r,

  # Note: for now, don't explicitly deny write access so --devmode isn't broken
  # but eventually we may conditionally deny this since it allows the process
  # to increase the oom heuristic of other processes (make them more likely to
  # be killed). Once AppArmor kernel var is available to solve this properly,
  # this can safely be allowed since non-root processes won't be able to
  # decrease the value and root processes will only be able to with
  # 'capability sys_resource,' which we deny be default.
  # deny owner @{PROC}/@{pid}/oom_{,score_}adj w,

  # Eases hardware assignment (doesn't give anything away)
  /etc/udev/udev.conf r,
  /sys/       r,
  /sys/bus/   r,
  /sys/class/ r,

  # this leaks interface names and stats, but not in a way that is traceable
  # to the user/device
  @{PROC}/net/dev r,
  @{PROC}/@{pid}/net/dev r,

  # Read-only of this snap
  /var/lib/snapd/snaps/@{SNAP_NAME}_*.snap r,

  # Read-only of snapd restart state for snapctl specifically
  /var/lib/snapd/maintenance.json r,

  # Read-only for the install directory
  # bind mount used here (see 'parallel installs', above)
  @{INSTALL_DIR}/{@{SNAP_NAME},@{SNAP_INSTANCE_NAME}}/                   r,
  @{INSTALL_DIR}/{@{SNAP_NAME},@{SNAP_INSTANCE_NAME}/@{SNAP_REVISION}}/    r,
  @{INSTALL_DIR}/{@{SNAP_NAME},@{SNAP_INSTANCE_NAME}/@{SNAP_REVISION}}/**  mrklix,

  # Read-only install directory for other revisions to help with bugs like
  # LP: #1616650 and LP: #1655992
  @{INSTALL_DIR}/{@{SNAP_NAME},@{SNAP_INSTANCE_NAME}}/**  mrkix,

  # Read-only home area for other versions
  # bind mount *not* used here (see 'parallel installs', above)
  owner @{HOME}/snap/@{SNAP_INSTANCE_NAME}/                  r,
  owner @{HOME}/snap/@{SNAP_INSTANCE_NAME}/**                mrkix,

  # Experimental snap folder changes
  owner @{HOME}/.snap/data/@{SNAP_INSTANCE_NAME}/                    r,
  owner @{HOME}/.snap/data/@{SNAP_INSTANCE_NAME}/**                  mrkix,
  owner @{HOME}/.snap/data/@{SNAP_INSTANCE_NAME}/@{SNAP_REVISION}/** wl,
  owner @{HOME}/.snap/data/@{SNAP_INSTANCE_NAME}/common/**           wl,

  owner @{HOME}/Snap/@{SNAP_INSTANCE_NAME}/                          r,
  owner @{HOME}/Snap/@{SNAP_INSTANCE_NAME}/**                        mrkixwl,

  # Writable home area for this version.
  # bind mount *not* used here (see 'parallel installs', above)
  owner @{HOME}/snap/@{SNAP_INSTANCE_NAME}/@{SNAP_REVISION}/** wl,
  owner @{HOME}/snap/@{SNAP_INSTANCE_NAME}/common/** wl,

  # Read-only system area for other versions
  # bind mount used here (see 'parallel installs', above)
  /var/snap/{@{SNAP_NAME},@{SNAP_INSTANCE_NAME}}/   r,
  /var/snap/{@{SNAP_NAME},@{SNAP_INSTANCE_NAME}}/** mrkix,

  # Writable system area only for this version
  # bind mount used here (see 'parallel installs', above)
  /var/snap/{@{SNAP_NAME},@{SNAP_INSTANCE_NAME}}/@{SNAP_REVISION}/** wl,
  /var/snap/{@{SNAP_NAME},@{SNAP_INSTANCE_NAME}}/common/** wl,

  # The snap-confine program creates an app-specific private restricted /tmp
  # and will fail to launch the app if something goes wrong. As such, we can
  # simply allow full access to /tmp.
  /tmp/   r,
  /tmp/** mrwlkix,

  # App-specific access to files and directories in /dev/shm. We allow file
  # access in /dev/shm for shm_open() and files in subdirectories for open()
  # bind mount *not* used here (see 'parallel installs', above)
  /{dev,run}/shm/snap.@{SNAP_INSTANCE_NAME}.** mrwlkix,
  # Also allow app-specific access for sem_open()
  /{dev,run}/shm/sem.snap.@{SNAP_INSTANCE_NAME}.* mrwlk,

  # Snap-specific XDG_RUNTIME_DIR that is based on the UID of the user
  # bind mount *not* used here (see 'parallel installs', above)
  owner /run/user/[0-9]*/snap.@{SNAP_INSTANCE_NAME}/   rw,
  owner /run/user/[0-9]*/snap.@{SNAP_INSTANCE_NAME}/** mrwklix,

  # Allow apps from the same package to communicate with each other via an
  # abstract or anonymous socket
  unix (bind, listen) addr="@snap.@{SNAP_INSTANCE_NAME}.**",
  unix peer=(label=snap.@{SNAP_INSTANCE_NAME}.*),

  # Allow apps from the same package to communicate with each other via DBus.
  # Note: this does not grant access to the DBus sockets of well known buses
  # (will still need to use an appropriate interface for that).
  dbus (receive, send) peer=(label=snap.@{SNAP_INSTANCE_NAME}.*),
  # In addition to the above, dbus-run-session attempts reading these files
  # from the snap base runtime.
  /usr/share/dbus-1/services/{,*} r,
  /usr/share/dbus-1/system-services/{,*} r,
  # Allow apps to perform DBus introspection on org.freedesktop.DBus for both
  # the system and session buses.
  # Note: this does not grant access to the DBus sockets of these buses, but
  # we grant it here since it is missing from the dbus abstractions
  # (LP: #1866168)
  dbus (send)
      bus={session,system}
      path=/org/freedesktop/DBus
      interface=org.freedesktop.DBus.Introspectable
      member=Introspect
      peer=(label=unconfined),

  # Allow apps from the same package to signal each other via signals
  signal peer=snap.@{SNAP_INSTANCE_NAME}.*,

  # Allow receiving signals from all snaps (and focus on mediating sending of
  # signals)
  signal (receive) peer=snap.*,

  # Allow receiving signals from unconfined (eg, systemd)
  signal (receive) peer=unconfined,

  # for 'udevadm trigger --verbose --dry-run --tag-match=snappy-assign'
  /{,usr/}{,s}bin/udevadm ixr,
  /etc/udev/udev.conf r,
  /{,var/}run/udev/tags/snappy-assign/ r,
  @{PROC}/cmdline r,
  /sys/devices/**/uevent r,

  # LP: #1447237: adding '--property-match=SNAPPY_APP=<pkgname>' to the above
  # requires:
  #   /run/udev/data/* r,
  # but that reveals too much about the system and cannot be granted to apps
  # by default at this time.

  # For convenience, allow apps to see what is in /dev even though cgroups
  # will block most access
  /dev/ r,
  /dev/**/ r,

  # Allow setting up pseudoterminal via /dev/pts system. This is safe because
  # the launcher uses a per-app devpts newinstance.
  /dev/ptmx rw,

  # Do the same with /sys/devices and /sys/class to help people using hw-assign
  /sys/devices/ r,
  /sys/devices/**/ r,
  /sys/class/ r,
  /sys/class/**/ r,

  # Allow all snaps to chroot
  capability sys_chroot,

  # Lttng tracing is very noisy and should not be allowed by confined apps. Can
  # safely deny for the normal case (LP: #1260491). If/when an lttng-trace
  # interface is needed, we can rework this.
  deny /{dev,run,var/run}/shm/lttng-ust-* rw,

  # Allow read-access on /home/ for navigating to other parts of the
  # filesystem. While this allows enumerating users, this is already allowed
  # via /etc/passwd and getent.
  @{HOMEDIRS}/ r,

  # Allow read-access to / for navigating to other parts of the filesystem.
  / r,

  # Snap-specific run directory. Bind mount *not* used here
  # (see 'parallel installs', above)
  /run/snap.@{SNAP_INSTANCE_NAME}/ rw,
  /run/snap.@{SNAP_INSTANCE_NAME}/** mrwklix,

  # Snap-specific lock directory and prerequisite navigation permissions.
  /run/lock/ r,
  /run/lock/snap.@{SNAP_INSTANCE_NAME}/ rw,
  /run/lock/snap.@{SNAP_INSTANCE_NAME}/** mrwklix,
  
  

  # Default rules for core base runtimes

  # The base abstraction doesn't yet have this
  /{,usr/}lib/terminfo/** rk,
  /usr/share/terminfo/** k,
  /usr/share/zoneinfo/** k,

  # for python apps/services
  /usr/bin/python{,2,2.[0-9]*,3,3.[0-9]*} ixr,
  # additional accesses needed for newer pythons in later bases
  /usr/lib{,32,64}/python3.[0-9]*/**.{pyc,so}           mr,
  /usr/lib{,32,64}/python3.[0-9]*/**.{egg,py,pth}       r,
  /usr/lib{,32,64}/python3.[0-9]*/{site,dist}-packages/ r,
  /usr/lib{,32,64}/python3.[0-9]*/lib-dynload/*.so      mr,
  /usr/include/python3.[0-9]*/pyconfig.h               r,

  # for perl apps/services
  /usr/bin/perl{,5*} ixr,
  # AppArmor <2.12 doesn't have rules for perl-base, so add them here
  /usr/lib/@{multiarch}/perl{,5,-base}/**            r,
  /usr/lib/@{multiarch}/perl{,5,-base}/[0-9]*/**.so* mr,

  # for bash 'binaries' (do *not* use abstractions/bash)
  # user-specific bash files
  /{,usr/}bin/bash ixr,
  /{,usr/}bin/dash ixr,
  /usr/share/terminfo/** r,

  # Common utilities for shell scripts
  /{,usr/}bin/arch ixr,
  /{,usr/}bin/{,g,m}awk ixr,
  /{,usr/}bin/base32 ixr,
  /{,usr/}bin/base64 ixr,
  /{,usr/}bin/basename ixr,
  /{,usr/}bin/bunzip2 ixr,
  /{,usr/}bin/busctl ixr,
  /{,usr/}bin/bzcat ixr,
  /{,usr/}bin/bzdiff ixr,
  /{,usr/}bin/bzgrep ixr,
  /{,usr/}bin/bzip2 ixr,
  /{,usr/}bin/cat ixr,
  /{,usr/}bin/chgrp ixr,
  /{,usr/}bin/chmod ixr,
  /{,usr/}bin/chown ixr,
  /{,usr/}bin/clear ixr,
  /{,usr/}bin/cmp ixr,
  /{,usr/}bin/cp ixr,
  /{,usr/}bin/cpio ixr,
  /{,usr/}bin/cut ixr,
  /{,usr/}bin/date ixr,
  /{,usr/}bin/dbus-daemon ixr,
  /{,usr/}bin/dbus-run-session ixr,
  /{,usr/}bin/dbus-send ixr,
  /{,usr/}bin/dd ixr,
  /{,usr/}bin/diff{,3} ixr,
  /{,usr/}bin/dir ixr,
  /{,usr/}bin/dirname ixr,
  /{,usr/}bin/du ixr,
  /{,usr/}bin/echo ixr,
  /{,usr/}bin/{,e,f,r}grep ixr,
  /{,usr/}bin/env ixr,
  /{,usr/}bin/expr ixr,
  /{,usr/}bin/false ixr,
  /{,usr/}bin/find ixr,
  /{,usr/}bin/flock ixr,
  /{,usr/}bin/fmt ixr,
  /{,usr/}bin/fold ixr,
  /{,usr/}bin/getconf ixr,
  /{,usr/}bin/getent ixr,
  /{,usr/}bin/getopt ixr,
  /{,usr/}bin/groups ixr,
  /{,usr/}bin/gzip ixr,
  /{,usr/}bin/head ixr,
  /{,usr/}bin/hostname ixr,
  /{,usr/}bin/id ixr,
  /{,usr/}bin/igawk ixr,
  /{,usr/}bin/infocmp ixr,
  /{,usr/}bin/kill ixr,
  /{,usr/}bin/ldd ixr,
  /{usr/,}lib{,32,64}/ld{,32,64}-*.so ix,
  /{usr/,}lib/@{multiarch}/ld{,32,64}-*.so* ix,
  /{,usr/}bin/less{,file,pipe} ixr,
  /{,usr/}bin/ln ixr,
  /{,usr/}bin/line ixr,
  /{,usr/}bin/link ixr,
  /{,usr/}bin/locale ixr,
  /{,usr/}bin/logger ixr,
  /{,usr/}bin/ls ixr,
  /{,usr/}bin/md5sum ixr,
  /{,usr/}bin/mkdir ixr,
  /{,usr/}bin/mkfifo ixr,
  /{,usr/}bin/mknod ixr,
  /{,usr/}bin/mktemp ixr,
  /{,usr/}bin/more ixr,
  /{,usr/}bin/mv ixr,
  /{,usr/}bin/nice ixr,
  /{,usr/}bin/nohup ixr,
  /{,usr/}bin/numfmt ixr,
  /{,usr/}bin/od ixr,
  /{,usr/}bin/openssl ixr, # may cause harmless capability block_suspend denial
  /{,usr/}bin/paste ixr,
  /{,usr/}bin/pgrep ixr,
  /{,usr/}bin/printenv ixr,
  /{,usr/}bin/printf ixr,
  /{,usr/}bin/ps ixr,
  /{,usr/}bin/pwd ixr,
  /{,usr/}bin/readlink ixr,
  /{,usr/}bin/realpath ixr,
  /{,usr/}bin/rev ixr,
  /{,usr/}bin/rm ixr,
  /{,usr/}bin/rmdir ixr,
  /{,usr/}bin/run-parts ixr,
  /{,usr/}bin/sed ixr,
  /{,usr/}bin/seq ixr,
  /{,usr/}bin/setpriv ixr,
  /{,usr/}bin/sha{1,224,256,384,512}sum ixr,
  /{,usr/}bin/shuf ixr,
  /{,usr/}bin/sleep ixr,
  /{,usr/}bin/sort ixr,
  /{,usr/}bin/stat ixr,
  /{,usr/}bin/stdbuf ixr,
  /{,usr/}bin/stty ixr,
  /{,usr/}bin/sync ixr,
  /{,usr/}bin/systemd-cat ixr,
  /{,usr/}bin/tac ixr,
  /{,usr/}bin/tail ixr,
  /{,usr/}bin/tar ixr,
  /{,usr/}bin/tee ixr,
  /{,usr/}bin/test ixr,
  /{,usr/}bin/tempfile ixr,
  /{,usr/}bin/tset ixr,
  /{,usr/}bin/touch ixr,
  /{,usr/}bin/tput ixr,
  /{,usr/}bin/tr ixr,
  /{,usr/}bin/true ixr,
  /{,usr/}bin/tty ixr,
  /{,usr/}bin/uname ixr,
  /{,usr/}bin/uniq ixr,
  /{,usr/}bin/unlink ixr,
  /{,usr/}bin/unxz ixr,
  /{,usr/}bin/unzip ixr,
  /{,usr/}bin/uptime ixr,
  /{,usr/}bin/vdir ixr,
  /{,usr/}bin/vim.tiny ixr,
  /{,usr/}bin/wc ixr,
  /{,usr/}bin/which{,.debianutils} ixr,
  /{,usr/}bin/xargs ixr,
  /{,usr/}bin/xz ixr,
  /{,usr/}bin/yes ixr,
  /{,usr/}bin/zcat ixr,
  /{,usr/}bin/z{,e,f}grep ixr,
  /{,usr/}bin/zip ixr,
  /{,usr/}bin/zipgrep ixr,

  # lsb-release
  /usr/bin/lsb_release ixr,
  /usr/bin/ r,
  /usr/share/distro-info/*.csv r,

  # For printing the cache (we don't allow updating the cache)
  /{,usr/}sbin/ldconfig{,.real} ixr,

  # Allow all snaps to chroot
  /{,usr/}sbin/chroot ixr,


}

limotux · June 4, 2025, 4:45pm

Neither me, I am no expert in anything even

Sorry, what is snap? And what does this you posted do?

I will highly appreciate simple not to techie replies as I am not that techie and apparmor seems a bit advanced for my humble knowledge and experience.

Svartis · June 4, 2025, 5:02pm

Sorry, snap is a package type by Canonical/Ubuntu which heavily utlilized apparmor to sandbox the included apps. It’s similar to flatpaks or appimages.

I used it as an example because the “hello-world-evil” app is provided by Canonical as a snap package, to test if apparmor was successfully installed and correctly configured.

Despite that, apparmor does not depend on snap and could be used in other usecases aswell.

limotux · June 4, 2025, 5:10pm

Oh! Okay.

I hope the experts or someone with experience with apparmor on EndeavourOS would enlighten me.

Learning never stopped here with this community.

cscs · June 4, 2025, 9:53pm

The second one is more correct.

Then apply that to something like your given application with a profile .. say Firefox .. then lets say an unscrupulous user adds “My Pink Ponies Super Extension Plus” addon that has some malicious code that would download some script to your root directory, etc etc. Thanks to the apparmor profile the malicious code fails to run because its actions are outside the allowed bounds of the profile.

If you somehow already have ‘maliciouscode.sh’ on your system and there is no corresponding apparmor profile for that software then it will be able to do whatever it likes as long as there are no other restrictions (filesystem privleges, root/sudo, etc).

AppArmor is not an AntiVirus framework … its more like sets of rules for apps to follow to make sure they do not misbehave and/or cannot be made to misbehave.

The type or category that AppArmor falls under is called Mandatory Access Control (MAC);

limotux · June 5, 2025, 12:39am

Thanks a lot @cscs
At least I know now what is the correct answer.
Maybe I will then look at other options, SELinux perhaps?

cscs · June 5, 2025, 1:02am

Technically such an apparmor setup as you describe is possible.

But again it would require the system be ‘completely profiled’ somehow or another.

But also I might mention that the idea is often more targeted - like for network-facing applications or those that may handle malicious files etc. (Though, taking a look, while there does not appear to be a ‘whole system’ or ‘default fallback’ profile .. the Arch packaging does provide a pretty large set of profiles to begin wtih, with more available at /usr/share/apparmor/extra-profiles/).

I could link back to the AppArmor FAQ, but this query does that with a little extra explaining:

https://security.stackexchange.com/questions/222526/is-apparmor-default-deny

Supposedly you could make a default-deny profile with something like

profile default /** {
  #insert default profile rules here
}

But I have not tried this and if it were restrictive enough for global default-deny then it would likely make the system unusable, and in order to make the system usable it would need to be less restrictive and end up becoming near useless.

SELinux is maybe closer to your ideal but between its complexity and how tightly it tends to lock things up .. it may be too much for most home users.

May I ask the impetus for ‘Security’? What is the threat model?

limotux · June 5, 2025, 12:23pm

Thanks @cscs
I know how linux is fine with malware in general. But as a hobby I’m trying to improve and learn. I have read that there are a few malware for Linux and ransomware that AFAIK can still infect Linux.

So I am trying to find a way to immunize my user files against anything.

But it seems that both apparmor or SELinux are both though good for security will be too restrictive and make the system unusable or best case not user friendly.

You got my point, I want to immunize user files against any malware.

I already installed apparmor (defaults).

Maybe the way to go is the standard way:

clamav, clamonacc, … etc to scan with the daemon
A hook perhaps that any file accessed (open, copy, move…) anywhere (local drive, flash disk, USB, LAN…) should first be scanned before the operation and gets blocked off infected.

This way no file with any malware would be opened.
(Been trying but could only scan on access files on local drive only not other locations)
What do you think?

cscs · June 13, 2025, 12:44am

First, sorry for leaving this unanswered..

Maybe what you want is something like rkhunter.

The idea is that it analyzes your system files, keeps a database, and then will search for deviations in permissions, hashes, hidden files, etc.

Due to how it works it is best implemented on a fresh system though. Or at least one that is known to be clean.

Here is the arch wiki: