This tool allows you to configure your privilege access management more securely on a single operating system.
Unlike sudo, this project sets the principle least privilege on its core features. Like sudo, this project wants to be usable. More than sudo, we care about configurators, and we try to warn configurators about dangerous manipulations.
By using a role-based access control model, this project allows us to better manage administrative tasks. With this project, you could distribute privileges and prevent them from escalating directly. Unlike sudo does, we don't want to give entire privileges for any insignificant administrative task, so you could configure it easily with capable command.
Requirement: rustc >= 1.70.0
- git clone https://github.com/LeChatP/RootAsRole
- cd RootAsRole
- sudo ./dependencies.sh
- sudo ./configure.sh
- sudo make install
Note: The configure.sh installs cargo and bpf-linker rust programs manually into /usr/local/bin. You can refuse to install it this way, but these are mandatory to build the program. Depending on your distribution or how you want to install this software, you may know that most rust binaries are installed to $HOME/.cargo/bin. When you use sudo to configure, these binaries are installed in the effective user home directory. You may need to move these binaries to a known-user path.
Warning
This installation process gives by default the entire privileges set for the user which execute sudo. This means that the user which install this program will be privileged.
Execute privileged commands with a role-based access control system Usage: sr [OPTIONS] [COMMAND]... Arguments: [COMMAND]... Command to execute Options: -r, --role <ROLE> Role to select -t, --task <TASK> Task to select (--role required) -p, --prompt <PROMPT> Prompt to display -i, --info Display rights of executor -h, --help Print help (see more with '--help') -V, --version Print version
If you're accustomed to utilizing the sudo tool and find it difficult to break that habit, consider creating an alias :
alias sudo="sr"sr chattr -i /etc/security/rootasrole.xml
sr nano /etc/security/rootasrole.xmlThis will remove immutable bit flag on the configuration and open text editor for the configuration file.
Use capable program, it will listen every capabilities requests and display them to you.
You may give us your feedbacks about RootAsRole here:
https://docs.google.com/forms/d/e/1FAIpQLSfwXISzDaIzlUe42pas2rGZi7SV5QvUXXcDM9_GknPa8AdpFg/viewform
https://www.youtube.com/watch?v=2Y8hTI912zQ
Traditionally, administering Linux systems is based on the existence of one powerful user (called superuser) who detains alone the complete list of the system's privileges. However, this administrative model is not respecting the least privilege principle because all programs executed in the context of the superuser obtain much more privileges than they need. For example, tcpdump, a tool for sniffing network packets, requires network capabilities to run. However, by executing it in the context of superuser, tcpdump obtains the complete list of systems' privileges, event reboot functionnality. Thus, the traditional approach of Linux administration breaks the principle of the least privilege that ensures that a process must have the least privileges necessary to perform its job (i.e., sniff packet networks). As a result, an attacker may exploit the vulnerabilities of tcpdump to compromise the whole system when the process of tcpdump possesses the complete list of root privileges.
RootAsRole module implements a role-based approach for distributing Linux capabilities to users. Our module contains the sr (switch role) tool that allows users to control the list of privileges they give to programs. Thus, with our module, users can stop using sudo and su commands that don't allow controlling the list of privileges granted to programs. Some tools already permit control of the list of privileges to give to programs, such as setcap and pam_cap module. However, these tools necessitate the use of extended attributes to store privileges. Storing privileges in extended attributes causes many different problems (see below motivation scenarios). Our module allows assigning Linux capabilities without the need to store the Linux capabilities in the extended attributes of executable files. Our work leverages a new capability set added to the Linux kernel, Ambient Set.
Our module is compatible with LSM modules (SELinux, AppArmor, etc.) and pam_cap.so. So administrators can continue using pam_cap.so along with our module. Finally, the RootAsRole module includes the capable tool, which helps Linux users know the privileges an application asks for.
As you may know with this RBAC model, it is possible for multiple roles to reference the same command for the same users. Since we do not ask by default the role to use, our tool applies an smart policy to choose a role using user, group, command entry and least privilege criteria. We apply a partial order comparison algorithm to decide which role should be chosen :
- Find all the roles that match the user id assignment or the group id, and the command input
- Within the matching roles, select the one that is the most precise and least privileged :
- user assignment is more precise than the combination of group assignment
- the combination of group assignment is more precise than single group assignment
- exact command is more precise than command with regex argument
- command with regex argument is more precise than a wildcarded command path
- wildcarded command path is more precise than wildcarded command path and regex args
- wildcarded command path and regex args is more precise than complete wildcard
- A role granting no capability is less privileged than one granting at least one capability
- A role granting no insecure capability is less privileged than one at least one insecure capability
- A role granting insecure capability is less privileged than one granting all capabilities.
- A role without setuid is less privileged than one has setuid.
- if no root is disabled, a role without 'root' setuid is less privileged than a role with 'root' setuid
- A role without setgid is less privileged than one has setgid.
- A role with a single setgid is less privileged than one that set multiple gid.
- if no root is disabled, A role with multiple setgid is less privileged than one that set root gid
- if no root is disabled, A role with root setgid is less privileged than one that set multiple gid, particularly using root group
- A role that enables root privileges is less privileged than one which disables root privileges (see "no-root" feature)
- A role that disables the Bounding set feature in RootAsRole is less privileged than one that enables it
After these step, if two roles are conflicting, these roles are considered equal (only the environment variables are different), so configurator is being warned that roles could be in conflict and these could not be reached without specifing precisely the role to choose (with --role option). In such cases, we highly recommend to review the design of the configured access control.
Our module has been tested on:
- Ubuntu>=16.04
- Debian>=10
- ArchLinux
After the installation you will find a file called rootasrole.xml in the /etc/security directory. You could configure it with chsr command or you could configure this file in order to define the set of roles and assign them to users or group of users on your system. Once configuration is done, a user can assume a role using the ‘sr’ tool that is installed with our package.
Since V2.0 of RootAsRole, we created a new tool that permits to retrieve capabilities asked by a program or a service. This can be very important when a user wants to configure the sr tool in order to inject the capabilities requested by a program. Please note that you should pay attention to the output of the tool, especially with regards the cap_sys_admin capability. In most cases, programs don't need this capability but we show it because this what Linux kernel returns to the capable tool.
Ahmad Samer Wazan : ahmad-samer.wazan@irit.fr
Rémi Venant: remi.venant@gmail.com
Guillaume Daumas : guillaume.daumas@univ-tlse3.fr
Eddie Billoir : eddie.billoir@gmail.com
Anderson Hemlee : anderson.hemlee@protonmail.com
Romain Laborde : laborde@irit.fr
This logo were generated using DALL-E 2 AI, for any license issue or plagiarism, please note that is not intentionnal and don't hesitate to contact us.
[1] PAM repository : https://github.com/linux-pam/linux-pam
[2] libcap repository : https://github.com/mhiramat/libcap
Very helpful site, where you can find some informations about PAM, libcap and the capabilities:
[3] Original paper about capabilities : https://pdfs.semanticscholar.org/6b63/134abca10b49661fe6a9a590a894f7c5ee7b.pdf
[4] Article about the capabilities : https://lwn.net/Articles/632520/
[5] Article about Ambient : https://lwn.net/Articles/636533/
[6] Simple article with test code for Ambient : https://s3hh.wordpress.com/2015/07/25/ambient-capabilities/
[7] Article about how PAM is working : https://artisan.karma-lab.net/petite-introduction-a-pam
[8] A very helpful code about how to create a PAM module : https://github.com/beatgammit/simple-pam
Source of the scenarios code:
[9] Where I have found the simple Python code for HTTP server : https://docs.python.org/2/library/simplehttpserver.html
[10] Where I have found the simple PRELOAD code : https://fishi.devtail.io/weblog/2015/01/25/intercepting-hooking-function-calls-shared-c-libraries/
[11] Serge E.Hallyn, Andrew G.Morgan, “Linux capabilities: making them work”, The Linux Symposium, Ottawa, ON, Canada (2008), https://www.kernel.org/doc/ols/2008/ols2008v1.pages-163.172.pdf