Mandatory Access Control with AppArmor
Monitoring Changes
The process described in the preceding section works well for a constant script. If any changes are made to the script or any program, AppArmor will restrict the functioning of the modified code, since those changes were not defined in the profile.
The test script creates, copies, then removes a file. I will now modify the script by adding a soft link to the previously created test.txt
file. If you run the program again, you will notice that the ln -s test.txt
command has been denied permission (Listing 4).
Listing 4
Permission Denied
01 shashwat@shash-nix:~/appar_t$ ./aatest 02 This is a test for apparmor capabilities. 03 ./aatest: line 6: /bin/ln: Permission denied 04 File created 05 File Copied 06 File has been deleted 07 Test successful
To allow this new function, you have to modify the previously created AppArmor profile. Simply, use the command aa-logprof
, and a new Utility access prompt will appear, asking you to grant new additional privileges to the profile (Listing 5).
Listing 5
aa-logprof Command
01 sudo aa-logprof 02 [sudo] password for shashwat: 03 Reading log entries from /var/log/syslog. 04 Updating AppArmor profiles in /etc/apparmor.d. 05 06 Profile: /home/shashwat/appar_t/aatest 07 Execute: /bin/ln 08 Severity: unknown 09 10 (I)nherit / (C)hild / (N)amed / (X) ix On / (D)eny / Abo(r)t / (F)inish
Once you grant the additional privileges, if you run the program again, you will not face any issues.
Predefined Profiles
To explore AppArmor on an app level, I will use a simple example of a generic app with a pre-configured profile and check how insufficient security on a generic app can cause a big vulnerability. Ubuntu used to default to ntpd for syncing time. Newer releases have shifted to timesyncd, but for more precise time changes, NTP is still the preferred service. The profile for NTP doesn't come bundled with AppArmor profiles, but it comes with the NTP package itself.
NTP requires root access with write privileges on root files, along with the need for an open port to get data from an online server. The combination of root privileges and open port access is a recipe for disaster, and in case of a bug, it can provide an opportunity for a system-wide exploit.
AppArmor curtails NTP's capabilities to limit POSIX permission and file access. The profile limits the capability to write access to a limited number of files and practically creates a whitelist (Listing 6). Even if the process is compromised, the hacker can only do so much, and the scope of the exploits is limited to permissions granted within the profile; in this case, it is limited to certain time-related files.
Listing 6
NTP Profile
01 capability ipc_lock, 02 capability net_bind_service, 03 capability setgid, 04 capability setuid, 05 capability sys_chroot, 06 capability sys_resource, 07 capability sys_time, 08 capability sys_nice, 09 10 /var/lib/ntp/*drift rw, 11 /var/lib/ntp/*drift.TEMP rw, 12 /var/log/ntp w, 13 /var/log/ntp.log w, 14 /var/log/ntpd w,
Removing Profiles
In most cases, it is not advisable to recuse an app or script, but if the need arises, AppArmor provides a provision to circumvent the scanning process. To remove a profile, you can either delete the profile present in /etc/apparmor.d/
or put the profile or its soft link under /etc/apparmor.d/disable
.
After you make the change, notify AppArmor using the following command:
apparmor_parser -R profile_path
To remove the ntpd process from the scanning, use the following command:
apparmor_parse -R /etc/apparmor.d/usr.sbin.ntpd
If you are deleting a profile, make sure you restart the AppArmor process.
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)