# User Armor: An Extension for AppArmor
###### Abstract  
AppArmor is a mandatory access control (MAC) system for Linux based on profiles. It focuses on protecting processes, without differentiating profiles based on the users running the processes themselves. Moreover, it does not implement inheritance mechanisms to simplify the management of profiles and avoid the duplication of rules. This work introduces UserArmor, an extension of AppArmor that overcomes the aforementioned limitations by allowing specific profiles to be associated with users and implementing an inheritance system to reduce complexity, improve reusability, and ensure consistency in security rules. An application to Answer Set Programming is discussed. m +
Footnote †: journal: _Algorithms_  
m _arxiv 1 (2015) 11 - 11  
/var/log/my_confined_app/user1.logrw, } profileuser2 {... /var/log/my_confined_app/user2.logrw, } } Therefore, when the application is executed by user1, the subprofile user1 is enforced, and in this way, access to the user2.logfile is inhibited at kernel level, even in the case of bugs in the application. Another limitation of AppArmor is the absence of an inheritance mechanism for profile policies. Even if profiles can be nested, creating a seemingly hierarchical structure, AppArmor subprofiles are designed to define different security rules for subprocesses of an application. The way they are designed, subprofiles do not inherit the rules of the main profile, as it is possible that a subprocess needs a less restrictive security policy to work correctly. Technically, AppArmor implements a notion of abstractions to reuse common rules; such rules are stored in abstraction files and can be reused in other security policies via the #include directive. However, abstractions are an all or nothing option: it is not possible to select specific rules within an abstraction, for example, based on the user running the process. Due to the absence of inheritance mechanisms, policy management is cumbersome and prone to errors, especially in complex environments where configurations must be updated frequently or affect multiple users. **Example 2**. : _Consider a Bash Application my_confined_app that needs the cat command to read a configuration file and access the network. The application can be run by two users, both sudors, only one of whom needs administrative capabilities. As in Example 1, users must have read and written access to their log files. The use of AppArmor that we propose would therefore need the following file: #include <tunables/global> /usr/bin/my_confined_app { profileuser1 { #include <abstractions/base> #include <abstractions/bash> /usr/bin/my_confined_app _r, /etc/my_confined_app.conf r, /usr/bin/cat iz,  networkinet, /var/log/my_confined_app/user1.logrw, } profileuser2 { #include <abstractions/base> #include <abstractions/bash> /usr/bin/my_confined_app r, /etc/my_confined_app.conf r, /usr/bin/cat iz,  capability sys_admin,  networkinet, /var/log/my_confined_app/user2.logrw, } } Above, the included abstractions set common permissions for Bash scripts, including access to.bash_profile,.bash_rc and.profile files. The file above has several duplicate rules. The extension proposed in this paper provides an inheritance system by which the described scenario can be modeled as follows:  
#include<tumables/global> /usr/bin/my_confined_app { #include<abstractions/base> #include<abstractions/bash> /usr/bin/my_confined_app r, /etc/my_confined_app.conf r, /usr/bin/cat iz, #oselectable(adam)capabilitysys_admin, #oselectable(net)networkinet,  
profileuser1{ #oselect:admnet /var/log/my_confined_app/user1.logru, } profileuser2{ #oselect:net /var/log/my_confined_app/user2.logru, } } In the above policy file, the #oselectable and #oselect directives avoid the duplication of rules. Their usage is detailed in Section 3. This paper presents UserArmor, an extension of AppArmor, with the goal of achieving greater granularity in user-level security policy management, and introducing an inheritance system based on tags.