https://github.com/LeChatP/RootAsRole

A memory-safe and security-oriented alternative to sudo/su commands
https://github.com/LeChatP/RootAsRole

capabilities linux rbac rust su sudo

Last synced: about 1 month ago
JSON representation

A memory-safe and security-oriented alternative to sudo/su commands

• Host: GitHub
• URL: https://github.com/LeChatP/RootAsRole
• Owner: LeChatP
• License: gpl-3.0
• Created: 2018-08-28T14:35:23.000Z (about 6 years ago)
• Default Branch: main
• Last Pushed: 2024-05-22T12:19:20.000Z (4 months ago)
• Last Synced: 2024-05-22T12:48:05.643Z (4 months ago)
• Topics: capabilities, linux, rbac, rust, su, sudo
• Language: Rust
• Homepage: https://lechatp.github.io/RootAsRole/
• Size: 5.49 MB
• Stars: 123
• Watchers: 8
• Forks: 6
• Open Issues: 2
• Metadata Files:
  • Readme: README.md
  • Changelog: CHANGELOG.md
  • License: LICENSE
  • Security: SECURITY.md

Awesome Lists containing this project

README

        




  

 

 


  







 

 

 



# RootAsRole (V3.0.0-alpha.5) : A memory-safe and security-oriented alternative to sudo/su commands

**RootAsRole** is a project to allow Linux/Unix administrators to delegate their administrative tasks access rights to users. Its main features are :

* [A structured access control model based on Roles](https://dl.acm.org/doi/10.1145/501978.501980)

  * [Role hierarchy](https://dl.acm.org/doi/10.1145/501978.501980)

  * [Static/Dynamic Separation of Duties](https://dl.acm.org/doi/10.1145/501978.501980)

* [Linux Capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html) support, to minimize the privileges of the user executing the command.

  * Prevent the escalation of privileges via Bounding set manipulation.

* [Highly configurable](chsr/README.md) with a simple command line interface. This interface is designed to be as easy as `ip` command.

  * File relocation ability.

  * Multi-layered and inheritable execution environment configuration.

  * Interoperable and evolvable by using [JSON](https://www.json.org/) as the main configuration file format.

* Command matching based on commonly-used open-source libraries:

  * [glob](https://docs.rs/glob/latest/glob/) for binary path

  * [PCRE2](https://www.pcre.org/) for command arguments

##   You can find every interesting resources using [the RootAsRole User/Knowledge/Reference Guide Book](https://lechatp.github.io/RootAsRole/).

## Installation

### How to Build

Requirement: rustc >= 1.70.0

  1. `git clone `

  1. `cd RootAsRole`

  1. `. ./dependencies.sh`

  1. `sudo ./configure.sh`

  1. `make install`

**[What does the installation do?](https://lechatp.github.io/RootAsRole/guide/installation.html#what-does-the-installation-script-do)**

> [!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.**

### Usage


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 : 

```sh

alias sudo="sr"

```

However you won't find out exact same options as sudo, you can use the `--role` option to specify the role you want to use instead.

## Why do you need this tool ?

|                                     | setcap | sudo             | sr |

|-------------------------------------|--------|------------------|----|

| Change user                         |        | ✅ but mandatory  | ✅  |

| Change groups                       |        | ✅ but mandatory  | ✅  |

| Manage environment variables        |        | ✅                | ✅  |

| Strict command matching             |        | ✅ with wildcards      | ✅ with PCRE and glob |

| Interoperable configuration/policy  |        | ✅ only with LDAP | ✅ with JSON |

| Set capabilities                    | ✅      |                  | ✅ with Ambient set |

| Prevent direct privilege escalation |        |                  | ✅ with Bounding set |

| Do not trust authorized users by default |        |                  | ✅ |

| Evolvable configuration/policy      |        |                  | ✅ with JSON |

| Scalable access control             |        |                  | ✅ with RBAC |

Traditional Linux system administration relies on a single powerful user, the superuser (root), who holds all system privileges. This model does not adhere to the principle of least privilege, as any program executed with superuser rights gains far more privileges than necessary. For example, `tcpdump`, a tool for sniffing network packets, only needs network capabilities. However, when run as the superuser, tcpdump gains all system privileges, including the ability to reboot the system. This excessive privilege can be exploited by attackers to compromise the entire system if tcpdump has vulnerabilities or their developers performs a supply chain attack.

The RootAsRole project offers a role-based approach for managing Linux capabilities. It includes the sr (switch role) tool, which allows users to control the specific privileges assigned to programs.

`Sudo` and `su` are the most common tools for managing privileges in Linux. However, they have several limitations. For example, when an user wants to change owner of a file, they must have the `CAP_CHOWN` capability in order to execute `chown` command. However, the `sudo` tool change the user ID to another one, and this user is root by default, which gives the user all the capabilities of the root user. Additionnally to not allow the user to have only the `CAP_CHOWN` capability, the sudo tool change the user ID to root, which is not necessary for the `chown` command. The RootAsRole project allows the user to have only the `CAP_CHOWN` capability without changing user, which is more secure.

While tools like `setcap` and the `pam_cap` module also manage privileges, they only handle this specific function, which is for limited administrative usages. For example, when you need to use `apt` to install a package, you may not only need cap_dac_override (to read/write files arbitrary) but also to change effective user ID to root. Indeed, without the setuid, every installed file configuration will be owned by the user who executed the command, making file configuration owners inconsistent. This is why the RootAsRole project is essential for managing the entire user credential structure.

Additionnally, `setcap` is applied to the binary file, which means that the capabilities are fixed for every program use-case. This is not ideal for a multi-user system, where different users may need different capabilities for the same program.

Furthermore, the `pam_cap` module is applied to the PAM user session, which means that the capabilities are fixed for every user's session. This is not ideal as administrator do not need these capabilities for every commands and every sessions.

The RootAsRole project is compatible with LSM (Linux Security Modules) such as SELinux and AppArmor, as well as pam_cap.so. Administrators can continue using pam_cap.so alongside our project. Additionally, the project includes the capable tool, which helps users identify the privileges required by an application.

### How to configure RootAsRole

You can configure RootAsRole with the `chsr` command. This command permits you to create roles, tasks, and assign them to users or groups. You can find more information about this command in the [Configure RootAsRole](https://lechatp.github.io/RootAsRole/chsr/index.html) section.

#### How to Find Out the Privileges Needed for Your Command

To determine the privileges required for your command, you can use the capable program. This tool listens for capability requests and displays them to you. Here’s how to use it effectively:

1. **Run the capable program**: It will monitor and display all capability requests made by your command.

1. **Analyze the output**: Pay close attention to the capabilities requested. It's common to see capabilities like CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH because many programs attempt to access files the user doesn't have permission to read. However, these capabilities are often not essential. Additionally, be aware that the Linux kernel may return the cap_sys_admin capability, even if it is not necessary.

1. **Filter unnecessary capabilities**: Determine if the requested capabilities are truly needed. If they are not, consider switching to an appropriate user with the necessary access rights.

1. **Handle missing privileges**: If your program fails to execute due to missing privileges, try granting the specific missing privileges one at a time. Test the program after each change until it works as expected.

By following these steps, you can identify and manage the necessary privileges for your command more effectively.

## Compatibility

Our project has been manually tested on (tests in may 2023):

* Ubuntu>=16.04

* Debian>=10

* ArchLinux

In june 2024, we performed automated `capable` tests with Vagrant on the following distributions:

* ❌ Centos 7 → Kernel too old (3.1)

* ✅ Centos 8

* ❌ Debian 10 → Dev dependencies unavailable, it should work once compiled

* ✅ Debian 11

* ✅ Fedora 37

* ✅ RedHat 9

* ✅ Ubuntu 22.04

* ✅ ArchLinux

This doesn't mean that earlier versions of these distributions are incompatible; it simply indicates they haven't been tested yet. However, if you encounter issues during the compilation process, they are likely due to dependency problems. In theory, the RootAsRole project should work on any Linux distribution with a kernel version of 4.1 or higher. However, since BTF (BPF Type Format) is becoming a mandatory requirement, [the kernel must be compiled with many features enabled](https://github.com/iovisor/bcc/blob/master/INSTALL.md#kernel-configuration).

## Contributors

Ahmad Samer Wazan : 

Rémi Venant: 

Guillaume Daumas : 

Eddie Billoir : 

Anderson Hemlee : 

Romain Laborde : 

## About Logo

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.

## Licence notice

This project includes [sudo-rs](https://github.com/memorysafety/sudo-rs) code licensed under the Apache-2 and MIT licenses: 

We have included cutils.rs, securemem.rs to make work the rpassword.rs file. Indeed, We thought that the password was well managed in this file and we have reused it. As sudo-rs does, rpassword.rs is from the rpassword project (License: Apache-2.0). We use it as a replacement of the rpassword project usage.

## References

[1] PAM repository : 

[2] libcap repository : 

Very helpful site, where you can find some informations about PAM, libcap and the capabilities:

[3] Original paper about capabilities : 

[4] Article about the capabilities : 

[5] Article about Ambient : 

[6] Simple article with test code for Ambient : 

[7] Article about how PAM is working : 

[8] A very helpful code about how to create a PAM module : 

Source of the scenarios code:

[9] Where I have found the simple Python code for HTTP server : 

[10] Where I have found the simple PRELOAD code : 

[11] Serge E.Hallyn, Andrew G.Morgan, “Linux capabilities: making them work”, The Linux Symposium, Ottawa, ON, Canada (2008),