AppArmor vs SELinux

Posted by: Tuyen Pham Thanh 2 years, 8 months ago

(0 comments)

SELinux controls access based on the labels of the files and processes while AppArmor controls access based on the paths of the program files. While AppArmor is easier in administration, the SELinux system is more secure.
AppArmor's motto is to allow everything then tighten gradually. In contrast, SELinux refuses everything then loosens up gradually. Right here we have seen that SELinux places more emphasis on security. For example, for preventing applications from accessing the password file (/etc/shadow), SELinux only needs to grant a few dedicated programs permission while AppArmor is difficult to prevent thousands of applications if don’t want to say impossible in the case of a strange program that has no profile and is therefore not confined. The AppArmor's App prefix shows us that it cares about the apps rather than the system. Below is a detailed comparison in the present moment

AppArmor's advantages over SELinux
AppArmor is an application armor with the following advantages:

• Easy to administer because of the simple policy rules. For example, an administrator only needs to write ix for an executable that is equivalent to the full permissions of domain non-transition execution in SELinux.
• Administrators can write the policy directly by editing profiles without compiling the policy into binaries. However, since the SELinux security policy has been modularized, this AppArmor advantage no longer stands out.
• AppArmor is supported by snapd by default. The profiles are available for every snaps in the AppArmor system while to achieve the desired security performance SELinux administrators or builders have to spend time to write policy modules for each snap.
  

Disadvantages of AppArmor compared to SELinux
AppArmor's main downside is its security problem and failure to catch up with kernel code, namely:

• AppArmor focuses on snaps, the default policy almost does not confine programs in the system, and lacks many supportive policy modules (profiles). Meanwhile, the SELinux default policy has relatively complete policy modules for the system and all applications.
• Failure to prevent all apps (except dedicated programs) from accessing the password file. A new program generally has no profile and no confinement.
• Classic snaps are not confined (complain mode) in AppArmor while SELinux can confine every snap.
• AppArmor's policy rule is not as grained as SELinux, and it lacks flexibility. For example, when an app wants to watch a directory with a large number of files causing the number of watches to exceed the limit for the user (/proc/sys/fs/inotify/max_user_watches), how does AppArmor policy prevent that? SELinux simply doesn't grant the app watch permission to watch that directory. AppArmor doesn't have this permission for directories and files.
• Lack of permissions for network rules.
• Not catching up with kernel code. The official patches only supports up to 4.15, of course there is no official patch for linux-5.x.
• Policy loading takes longer so the AppArmor system starts up longer than the SELinux system.

Omarine has begun to support AppArmor
The Omarine has supported both SELinux and AppArmor. If you want to use AppArmor, add the kernel command-line parameters as follows

security=apparmor apparmor=1

Or add those parameters to the GRUB_CMDLINE_LINUX line in the /etc/default/grub file and recreate the GRUB configuration:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Below is an additional profile used to confine XScreenSaver

#include <tunables/global>

/usr/bin/xscreensaver {
  #include <abstractions/base>
  #include <abstractions/consoles>
  #include <abstractions/fonts>
  #include <abstractions/nameservice>
  #include <abstractions/user-tmp>

  capability kill,
  capability mknod,
  capability sys_nice,

  network unix stream,

  dbus,

  deny /etc/shadow r,

  /bin/bash Ux,
  /etc/* r,
  /etc/fonts/** l,
  /etc/pam.d/* r,
  /sbin/unix_chkpwd Ux,
  /usr/bin/xscreensaver* ix,
  /usr/libexec/xscreensaver/* ix,
  /usr/share/X11/** r,
  /usr/share/fonts/X11/** w,
  /usr/share/mime/* r,
  /var/cache/fontconfig w,
  @{HOME}/.cache/xscreensaver/xscreensaver-getimage.cache rw,
  @{HOME}/.local/share/mime/* r,
  @{HOME}/.xscreensaver rw,
  @{PROC}[0-9]*/* rw,
  @{PROC}{cpuinfo,meminfo,uptime} r,
  @{run}dbus/system_bus_socket rw,
  @{run}nscd/socket rw,
  @{run}user/[0-9]*/bus rw,
  @{run}user/[0-9]*/gdm/Xauthority r,
  @{sys}** r,

}

Displaying AppArmor policy status
The aa-status command is used to present information about the current AppArmor policy

sudo aa-status

• ← SELinux: snapd: Confining snaps to their private domain
• Optional type in Swift →