# 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 code, clingo cannot access critical files, execute system commands, or connect to the internet, effectively neutralizing the RCE attack. Without UserArmor, the only alternative is to apply AppArmor restrictions to clingo globally. This means that every instance of clingo on the backend server would be restricted, including those run by legitimate users (e.g., via SSH). This is problematic because some users may need unrestricted access to clingo. For example, researchers or developers using clingo from the terminal might rely on @-terms for legitimate purposes, such as reading external files and making network requests to fetch data. By applying a global AppArmor profile to clingo, all users on the system would be restricted in the same way, even those who should have full access. A possible alternative to UserArmor is to execute clingo inside a sandbox, such as Bubblewrap (bwrap). Bubblewrap is a lightweight user-space sandboxing tool that can create isolated environments for applications. For example, clingo could be executed inside a Bubblewrap sandbox as follows:  
$ bwrap -unshare-net -ro-bind /usr/bin/clingo /usr/bin/clingo \  --ro-bind /usr/lib /usr/lib -ro-bind /lib /lib --ro-bind /lib64 /lib64 \  --ro-bind /var/www/clingo_input /input /usr/bin/clingo /input/encoding.lp This setup prevents network access (--unshare-net) and restricts filesystem access (--ro-bind for read-only mounts). However, sandboxing introduces more overhead than AppArmor/UserArmor (every clingo execution requires setting up a new isolated environment) and is more difficult to manage (running a sandbox requires an invasive change in how clingo is invoked, which may not be practical in existing systems). We provide scripts showcasing the above scenarios as follows:  
* Unconfined execution of clingo: This script configures a web app vulnerable to RCE and subject to system takeover. * Confined execution of clingo via AppArmor: This script configures a web app that is not vulnerable to RCE, but SSH users are subject to the same restriction of the web app. * Confined execution of clingo via UserArmor: This script configures a web app that is not vulnerable to RCE, and SSH users are free to use clingo as they would normally do. Sand-boxed execution of clingo via Bubblewrap: This script configure a web app that is not vulnerable to RCE but requires a new isolated for each execution of clingo. The script files are available online ([[https://github.com/pierpaolosestito-dev/ASPArmor](https://github.com/pierpaolosestito-dev/ASPArmor)]([https://github.com/pierpaolosestito-dev/ASPArmor](https://github.com/pierpaolosestito-dev/ASPArmor)); accessed on 13 February 2025). We ran a second experiment using the aforementioned scripts on a 13 th Gen Intel(R) Core(TM) i7-1360P @ 2.2 GHz CPU with 32 GB RAM. In this experiment, we repeatedly call clingo to produce 10 thousand integers with the program number(1..10,000). We opted for such a simple, deterministic program to obtain a stable performance of clingo. As shown in Figure 5, the results confirm the observations from the previous section as follows: UserArmor introduces a negligible overhead, and its performance is superior to Bubblewrap. To sum up, hardening clingo in a web-based environment is crucial due to its support for @-terms, which can lead to RCE vulnerabilities. While sandboxing tools like Bubblewrap can provide isolation, they introduce overhead and require modifications to the execution workflow. UserArmor, on the other hand, offers a more lightweight and kernel-enforced approach, allowing administrators to restrict clingo permissions only for the web service user (www-data), without affecting other users who might need full access.