Some issues in the management of Linux capabilities by AppArmor

AppArmor is one of the most known LSM modules that allows the application of MAC access control rules. This tool is known to be easy to use when it is compared to SELinux. 

As a part of my research work, I wanted to know how AppArmor manages Linux capabilities (administrative privileges for Linux).  So I have decided to build a shell script that requires administrative privileges and see how AppArmor can restrict this shell script. This work has allowed me to identify some important issues.

My script includes two different commands that require two Linux capabilities:

• chown permits to change the owner of the file. This command requires the Linux capability cap_chown.

• nc -l 80 permits to create a process that listens to the port 80. This command requires the Linux capability cap_net_bind_service.

Here is my shell script:

#!/bin/bash

if  chown test file1.txt  ; then

     echo "owner changed"

 else

     echo "failed"

nc -l 80

 

The script is named admin.sh. I have added the user test and also created a file called file1.txt before running the script.

To create an AppArmor profile for my script, I have run in one terminal the command sudo aa-genprof /home/samer/Desktop/admin.sh & run the script admin.sh in another terminal so that AppArmor can help me build the AppArmor profile of my script admin.sh.

From the figure above, we can notice that aa-genprof was able to detect many rules related to file accesses. The tool was also able to detect the needed Linux capabilities. As shown below, the capability cap_chown was detected and added explicitly to the profile of the script. Although the capability cap_net_bind_service was detected also, it was not added explicitly to the profile of the script, but imported through the inclusion of <abstractions/nis>, so we will not see it explicitly in the profile.

Now the script is enforced to the profile built by AppArmor. Every time we need to run the script, we should however continue to use the command sudo with the script. AppArmor allows a process to use the capabilities if the process has the privileges in its memory (i.e. in its Permitted & Effective) and also declared in its profile. So here the bash shell process that is running my script can have only cap_net_bind_service & cap_chown because sudo gives the whole list of administrative privileges and the profile contains only cap_chown & cap_net_bind_service. 

This management method of Linux capabilities can create a problem if someone tries to identify the privileged processes inside his system. Usually, we need to check the Permitted & Effective sets of any process to know whether it is a privileged process or not. Checking the Permitted & Effective sets of my Bash process that is running my script shows that it has the full list of Linux capabilities (0x1ffffffffff) when in fact it has only cap_chown & cap_net_bind_service.

• for /bin/bash admin.sh

• for nc -l 80

Another issue is that AppArmor is able to detect the Linux capabilities only when we run the tool or the script with sudo command. It means that the user has to give the to-be restricted tool the whole list of administrative privileges before being able to know the needed administrative privileges. 

To prove it, let's remove the profile of admin.sh from the kernel and try to see whether the aa-genprof will be able to detect the Linux capabilities.

• Remove the previous profile from the kernel:    sudo apparmor_parser -R home.samer.Desktop.admin.sh

• Delete the profile file: sudo rm home.samer.Desktop.admin.sh

Let's now try to use the tool aa-genprof to generate a new profile & run admin.sh without sudo

We can notice that aa-genprof was able to detect only the needed access to file resources but it was not able to detect the Linux capabilities. The admin.sh is now enforced by AppArmor, but it will not work even when we use sudo command as the needed capabilities are not in the profile.

However, we can see that the command 'nc -l 80' inside the admin.sh was able to run even when the capability net_bind_service was not detected by aa-genprof tool. The reason for this is that AppArmor has included the abstraction file nameservice that includes a set of predefined rules for network services. This file include another abstraction file (#include <abstractions/nis>) that includes the cap_net_bind_service capability. 

So to conclude, AppArmor management of Linux capabilities has three main issues:

1. The user has to give the to-be restricted tool all the administrative privileges to know the needed one. This method can be sometimes dangerous if the to-be restricted tool has some known vulnerabilities.

2. AppArmor is not applying the principle least privilege as it has included cap_bind_service in the profile of the tool even though the need for this capability was not detected.   

3. It is difficult to know the process that are privileged or not because AppArmor doesn't update the Permitted & Effective sets of the Privileged processes and also sometimes it is difficult to know this from checking the profile files as sometimes the capabilities are included in the abstraction files that are not usually verified by users.