Answer Set Programming is a declarative programming paradigm designed for solving complex combinatorial problems and is widely used in artificial intelligence, knowledge representation and automated reasoning. ASP can be used to develop web-based AI applications, where an ASP solver is executed in the backend server. While this approach is functional, it introduces serious security vulnerabilities if not properly implemented. This work introduces UserArmor, an extension of AppArmor, with the aim of hardening ASP solvers and other Linux processes on a per-user basis.
The state-of-the-art solverCLINGO[
CEUR Workshop
ISSN1613-0073 and tag-based inheritance mechanisms. User-level granularity is implemented via a hierarchical structure: each application has a base profile, and each user is linked to a nested subprofile. UserArmor associates each application with a directory of per-user subprofiles, stored in separate files for modularity. These are merged into a single mappings file, included via#include in the main policy. At load time, the kernel links user-specific profiles under names like confined_app//user_name. Inheritance is achieved through a tag-based system using#@selectable and #@select keywords, which enable reuse of rules without duplication. Their usage is detailed in Secti4o.n
We demonstrate how UserArmor can be applied toharden web-deployed ASP solvers like CLINGO, mitigating remote code execution risks by confining the execution environment of specific users (e.g., www-data) without afecting others. For instance, by defining a dedicated security profile for the web service user, CLINGO can be restricted withno file system access, no network access, and a minimal execution environment.
Looking ahead, we plan to further extend UserArmor by integratinAgnswer Set Programming techniques not only for theautomatic generation of user-specific policies , but also for reasoning about internal implementation concerns such aasutomated handling of inheritance and profile consistency . In particular, we envision converting audit logs and trace events (e.g., froAmuditd or SystemTap) into ASP facts, from which logic-based rules can derive abstract properties (e.g., inferrinngetwork_acceve agss("dns")) and enforce security constraints declaratively.
A UserArmor profile for www-data could look like this: profile www-data { # Deny access to the entire filesystem except for necessary paths deny / rwx, /usr/lib/** rm, # Allow read access only to the directory where ASP encodings are stored /var/www/clingo_input/** r, # No network access deny network, # Deny execution of system commands deny capability sys_admin, deny capability setuid, deny capability setgid, } With this policy, even if an attacker injects Python or Lua codcel, ingo cannot access critical files, execute system commands, or connect to the internet, efectively neutralizing the RCE attack.
In AppArmor, processes can be associated withprofiles that control access to system resources. Profiles are typically stored in/etc/apparmor.d/, named after the executable’s absolute path (with / replaced by .). A profile has the structure: profile NAME /ABSOLUTE/PATH {
RULES -> define access permissions
SUBPROFILES -> specify rules for subprocesses }
In the main profile, profile NAME can be omitted. Rules can apply to: Files: /ABSOLUTE/PATH FLAGS, where FLAGS includer (read), w (write), x (execute), andix (execute under current profile).
Capabilities: capability CAPABILITIES, where CAPABILITIES include kernel-level privileges (e.g., setuid).
Networking: network TYPE, with TYPE specifying communication types (e.gi.,net or inet6).
Any rule can be prefixed with deny to block access.
Key AppArmor tools includeaa-genprof (interactive profile generation), aa-logprof (profile updates from audit logs),apparmor_parser (profile verification and loading), and aa-complain, aa-enforce, aa-disable (to switch enforcement modes).
AppArmor supports rule reuse throughabstraction, which are dedicated files containing reusable sets of rules, included with#:include <file> or, conditionallyi:nclude if exists <file>.
Paths are relative to/etc/apparmor.d/. Missing files trigger an error unless the conditional form is used.
These files contain common permissions and access patterns for widely used applications or subystems, such as bash, nameservice, X11.
The closest work to ours is Paranoid Penguin9][, which improves AppArmor usability by providing a graphical interface for profile creation and management. This approach reduces configuration errors and makes AppArmor more accessible, but it does not alter the enforcement model or introduce new security features. UserArmor, instead, extends AppArmor’s model with fine-grained access control for multi-user environments and a tag-based inheritance system that avoids rule duplication.
Related research also investigates dynamic profiling, where policies adapt at runtime. Some proposals
ofload profile generation to the cloud for centralized control 1[
Traditional UNIX-based systems already provide basic user-level access control mechanisms, including ifle ownership and permission bits, group memberships, and POSIX Access Control Lists (ACLs). While efective for managing file and resource access, these mechanisms are not integrated with kernel-level security modules like AppArmor and lack process-level confinement or modular policy enforcement. Resource limits can be applied per user through PAM configurations (e.g.l,imits.conf ) [18, 19, 20], but these settings are coarse-grained and disconnected from application-specific security requirements. UserArmor instead ofers a unified and scalable approach to multi-user confinement.
Role-Based Access Control (RBAC) is also available in Linux through SELinux, which provides a
powerful yet complex security model based on types, roles, and domain2s1,[
The goal of this research is to provide an extension of AppArmor that overcomes the lack of user-level granularity and inheritance mechanisms. This motivated the study and implementation of UserArmor.
log file. The most restrictive AppArmor profile that allows the application to function would include: /var/log/my_confined_app/user1.log rw, /var/log/my_confined_app/user2.log rw, Further restrictions would break application logic, as each user needs access to their own log file. This creates a vulnerability: a bug could let user1 access user2’s file, violating confidentiality and integrity. To prevent this, we introduce per-user subprofiles: profile user1 { ...
/var/log/my_confined_app/user1.log rw, And profile user2 with ’rw’ permission on /var/log/my_confined_app/user2.log file. When the application is run by user1, the user1 subprofile is enforces, preventing any access to user2.log at the kernel level, even in the presence of application bugs. ■
While profiles can be nested, subprofiles define separate rules for subprocesses and do not inherit from the parent, as diferent privileges may be required.
AppArmor supports rule reuse viaabstractions, included with#include. However, abstractions are all-or-nothing and cannot adapt based on conditions such as the user identity. This makes policy management complex and error-prone in user-specific or frequently changing environments.
network access. It can be run by two sudo users, but only one needs administrative privileges. As in Example 1, each user must access their own log file. A standard AppArmor profile for this scenario would be:
} }
} #include <tunables/global> /usr/bin/my_confined_app { profile user1 { #include <abstractions/bash> /etc/my_confined_app.conf r, /usr/bin/cat ix, network inet, /var/log/my_confined_app/user1.log rw, profile user2 { #SAME RULES /var/log/my_confined_app/user2.log rw, Here, abstractionsinclude common Bash permissions (e.g., .bash_profile, .bash_rc, .profile), but many rules are duplicated across subprofiles. UserArmor addresses this with a tag-based inheritance mechanism that simplifies rule reuse: #include <tunables/global> /usr/bin/my_confined_app { #OTHER RULES #@selectable{adm} #@selectable{net} profile user1 { /var/log/my_confined_app/user1.log rw, } profile user2 { /var/log/my_confined_app/user2.log rw,
} } capability sys_admin, network inet,
■
UserArmor uses a tag system represented with a comment-based syntax, described below. Rules (and blocks) are associated with aliases (i.e., identifying strings).
Base rules. Untagged rules are considered essential and are automatically inherited by all subprofiles. Selectable rules. Rules starting with a tag#@selectable{ALIAS} are not inherited automatically (and are not part of the main profile), but can be included in the subprofiles via theirALIAS. Selectable blocks. A syntax similar to the previous one can be applied to rule blocks: Removable rules. Rules ending with a tag#@removable{ALIAS} are inherited in subprofiles unless explicitly removed by theirALIAS.
Subprofile inheritance. Subprofiles can select rules and blocks using the following ta#g@:select: ALIASES where ALIASES is a space-separated list of aliases. Selected rules and blocks are added to the basic rules. Untagged rules are added at the begin of each subprofile, unless their alias is listed in the following tag#:@remove: ALIASES
The tag system applies to profile files stored in a directory specific to the confined application. Each user has a profile file, and a central mappings file includes them all. Thismappings file is then included in the main profile under /etc/apparmor.d/. AppArmor loads subprofiles as confined_app//user_name, allowing UserArmor to select the correct one based on the current user.
Example 3 (Continuing Example 2). The scenario before is modeled with the profile file /etc/apparmor.d/usr.bin.my_confined_app:
#include <tunables/global> /usr/bin/my_confined_app { #include <abstractions/bash> /etc/my_confined_app.conf r, /usr/bin/cat ix, #@selectable{adm} capability sys_admin, #@selectable{net} network inet, include if exists <.usr.bin.my_confined_app/mappings> } The directory /etc/apparmor.d/.usr.bin.my_confined_app contains: • user1, associated to the first user, with the following content: profile user1 { #@select: adm net /var/log/my_confined_app/user1.log rw, } • user2, associated with the second user, has same structure as user1, but selects only the net tag, limiting access accordingly. • mappings, including the above files with the expansion of the selected permissions (e.g user1): profile user1 { #@select: adm net capability sys_admin, network inet, /var/log/my_confined_app/user1.log rw,
include if exists <.usr.bin.my_confined_app/mappings> directive into the application profile and generating /etc/apparmor.d/.usr.bin.my_confined_app/mappings. Untagged rules are treated as essential and inherited automatically. ■ UserArmor includes three command-line utilitieusa: -generate, ua-enforce, and ua-exec. ua-generate creates the required directory and one subprofile per user, preserving existing files (Root privileges are required).ua-enforce inserts the include if exists directive and generates themappings ifle based on tag selection (Also requires root).ua-exec selects and applies the correct subprofile using aa-exec. Usable by any user, butaa-exec should be executable only by root or members of thueserarmor group. Users outside the group will fall back to the base profile; group members use their dedicated subprofile.
Example 4 (Continuing Example 3). Starting from the base profile /etc/apparmor.d/usr.bin.my_confined_app, the following command generates the directory structure and empty subprofiles:
$ sudo ua-generate /usr/bin/my_confined_application --subprofiles=user1,user2
$ sudo ua-enforce /usr/bin/my_confined_application
$ ua-exec /usr/bin/my_confined_app arg1 arg2 ...
$ my_confined_app arg1 arg2 ...
would fall back to the base profile, with no access to /var/log/my_confined_app/user1.log. ■ We provide scripts for four scenarios: (i) Unconfinedclingo, where the web app is vulnerable to RCE and system compromise; (ii) AppArmor-confined, which prevents RCE but restricts all users, including those accessing via SSH; (iii) UserArmor-confined, which blocks RCE for the web app while allowing unrestricted SSH use ofclingo; and (iv) Bubblewrap sandboxed, which prevents RCE but requires a fresh isolated environment for each execution.
The script files are available onlineh(ttps://github.com/pierpaolosestito-dev/ASPArmo;raccessed 13 February 2025). We ran an experiment on a 13th Gen Intel(R) Core(TM) i7-1360P @ 2.2 GHz CPU with 32 GB RAM using a simple Bash script: cat /etc/my_confined_app.conf >> /var/log/my_confined_app/$USER.log
We repeatedly executedclingo on the program: number(1..10000)
UserArmor introduced negligible overhead. For example, after 50 calls, execution times were: Unconifned: 0.99s, AppArmor: 1.01s, UserArmor: 1.08s, Bubblewrap: 1.32s. Performance remained consistent across larger batches, with UserArmor consistently outperforming Bubblewrap.
In summary, securingclingo in web environments is essential due to the risk posed by @-terms, which enable RCE. Bubblewrap provides isolation but adds overhead and requires workflow changes. UserArmor ofers a lighter, kernel-level alternative: it restrictcslingo for the web user (www-data), while leaving other users unafected.
For completeness, we note thatclingo—like MiniZinc 2[
A central line of future work will be the integration of declarative reasoning techniques to support the automatic generation of UserArmor profiles. Building on existing approaches that use tools such as Auditd and SystemTap to monitor system events, we plan to convert these events into facts that can be processed by an ASP solver.
From these low-level facts, additional rules can derive higher-level properties (e.g. grouping raw TCP connection events into abstract facts such ansetwork_access("dns"), which can then be constrained by declarative policies.
Example 5. A concrete case is a log entry from Auditd like: type=SYSCALL msg=audit(...): exe="/usr/bin/clingo" comm="python3" syscall=2
file="/etc/passwd" which can be translated into the fact and combined with a constraint such as :- access(_, _, File, _), sensitive(File). to ensure that no policy allows access to sensitive files. Similarly, a network event like can be constrained with :- network_request(_, Host), Host != "trusted.example.org".
The solver will search for combinations of permissions that are both safe and minimal. High-level constraints - such as ”deny all network access except to domain X” - will be expressed as declarative rules. In this framework, logic is not just a description of the observed events but an active reasoning tool that: synthesizes profiles by automatically selecting permissions, verifies that generated policies satisfy safety constraints, and explains every decision by linking it to rules and facts.
This reasoning-based extension will make UserArmor a hybrid framework where static enforcement and logic-based reasoning cooperate to improve security in multi-user environments.
Beyond the integration of ASP-based reasoning, future development will also address the creation of administrative tools for managing user-specific profiles, including the ability to rename or delete them. It will further investigate the scalability of reasoning when large execution traces are collected and explore interactive workflows in which administrators can refine or approve the policies generated automatically. These directions aim to turn UserArmor into a practical yet research-oriented platform that combines secure Linux confinement with the flexibility of logic programming.
During the preparation of this work, the authors used ChatGPT-4o for grammar and spelling check. After using this tool, the authors reviewed and edited the content as needed and take full responsibility for the publication’s content. Com 2022, Melbourne, Australia, December 17-19, 2022, IEEE, 2022, pp. 822–829. URL: https://doi.org/10.1109/ISPA-BDCloud-SocialCom-SustainCom57177.2022.001.1d0oi:10.1109/ ISPA-BDCLOUD-SOCIALCOM-SUSTAINCOM57177.2022.00110. [17] H. Zhu, C. Gehrmann, Kub-sec, an automatic kubernetes cluster apparmor profile generation engine, in: 14th International Conference on COMmunication Systems & NETworkS, COMSNETS 2022, Bangalore, India, January 4-8, 2022, IEEE, 2022, pp. 129–137. URLh:ttps://doi.org/10.1109/ COMSNETS53615.2022.9668504. doi:10.1109/COMSNETS53615.2022.9668504. [18] A. G. Morgan, Pluggable authentication modules for linux: An implementation of a userauthentication api, Linux Journal 1997 (1997) 1–es. [19] K. Geisshirt, Pluggable authentication modules, Birmingham, UK: Packt Publishing 105 (2007). [20] V. Samar, Unified login with pluggable authentication modules (pam), in: Proceedings of the 3rd
ACM conference on Computer and communications security, 1996, pp. 1–10. [21] Z. C. Schreuders, T. McGill, C. Payne, Empowering end users to confine their own applications: The results of a usability study comparing selinux, apparmor, and fbac-lsm, ACM Trans. Inf. Syst.
Secur. 14 (2011). URL: https://doi.org/10.1145/2019599.2019604. doi:10.1145/2019599.2019604. [22] C. Shepherd, K. Markantonakis, Operating system controls, in: Trusted Execution Environments,
Springer, 2024, pp. 33–53. [23] S. Smalley, Configuring the selinux policy, NAI Labs Rep (2002) 02–007. [24] N. Nethercote, P. J. Stuckey, R. Becket, S. Brand, G. J. Duck, G. Tack, MiniZinc: Towards a standard CP modelling language, in: C. Bessiere (Ed.), CP 2007, Providence, RI, USA, September 23-27, 2007, Proceedings, volume 4741 ofLNCS, Springer, 2007, pp. 529–543. doi1:0.1007/ 978-3-540-74970-7\_38. [25] A. Ivliev, L. Gerlach, S. Meusel, J. Steinberg, M. Krötzsch, Nemo: A scalable and versatile datalog engine, in: M. Alviano, M. Lanzinger (Eds.), Proceedings 5th International Workshop on the Resurgence of Datalog in Academia and Industry (Datalog-2.0 2024) co-located with the 17th International Conference on Logic Programming and Nonmonotonic Reasoning (LPNMR 2024), Dallas, Texas, USA, October 11, 2024, volume 3801 oCf EUR Workshop Proceedings, CEUR-WS.org, 2024, pp. 43–47. URL: https://ceur-ws.org/Vol-3801/short3.pd.f [26] A. Ivliev, L. Gerlach, S. Meusel, J. Steinberg, M. Krötzsch, Nemo: Your friendly and versatile rule reasoning toolkit, in: P. Marquis, M. Ortiz, M. Pagnucco (Eds.), Proceedings of the 21st International Conference on Principles of Knowledge Representation and Reasoning, KR 2024, Hanoi, Vietnam.
November 2-8, 2024, 2024. URL: https://doi.org/10.24963/kr.2024/70. doi:10.24963/KR.2024/70. [27] M. Alviano, D. Cirimele, L. A. R. Reiners, Introducing ASP recipes and ASP chef, in: J. Arias, S. Batsakis, W. Faber, G. Gupta, F. Pacenza, E. Papadakis, L. Robaldo, K. Rückschloß, E. Salazar, Z. G. Saribatur, I. Tachmazidis, F. Weitkämper, A. Z. Wyner (Eds.), Proceedings of the International Conference on Logic Programming 2023 Workshops co-located with the 39th International Conference on Logic Programming (ICLP 2023), London, United Kingdom, July 9th and 10th, 2023, volume 3437CoEfUR Workshop Proceedings, CEUR-WS.org, 2023. URL: https://ceur-ws.org/Vol-3437/paper4ASPOCP.pd.f [28] M. Alviano, L. A. R. Reiners, ASP chef: Draw and expand, in: P. Marquis, M. Ortiz, M. Pagnucco (Eds.), Proceedings of the 21st International Conference on Principles of Knowledge Representation and Reasoning, KR 2024, Hanoi, Vietnam. November 2-8, 2024, 2024. URLh: ttps://doi.org/10.24963/ kr.2024/68. doi:10.24963/KR.2024/68. [29] M. Alviano, L. A. R. Reiners, Integrating minizinc with ASP chef: Browser-based constraint programming for education and prototyping, in: C. Dodaro, G. Gupta, M. V. Martinez (Eds.), Logic Programming and Nonmonotonic Reasoning - 17th International Conference, LPNMR 2024, Dallas, TX, USA, October 11-14, 2024, Proceedings, volume 15245 oLfecture Notes in Computer Science, Springer, 2024, pp. 174–186. URL: https://doi.org/10.1007/978-3-031-74209-5_14. doi:10. 1007/978-3-031-74209-5\_14. [30] M. Alviano, P. Guarasci, L. A. R. Reiners, I. R. Vasile, Integrating structured declarative language (SDL) into ASP chef, in: C. Dodaro, G. Gupta, M. V. Martinez (Eds.), Logic Programming and Nonmonotonic Reasoning - 17th International Conference, LPNMR 2024, Dallas, TX, USA, October 11-14, 2024, Proceedings, volume 15245 ofLecture Notes in Computer Science, Springer, 2024, pp.