Introduction

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

Usage

The main command line tool is sr. It allows you to execute a command by simply typing:

sr <command>

You can find more information about this command in the sr section.

The chsr command allows you to configure the roles and capabilities of the system. You can find more information about this command in the Configure RootAsRole section.

Our Research Articles

In 2021, we published our first research article about RootAsRole project [Wazan et al. 2021]. This article present the pilot implementation of RootAsRole project and the main features of the project.

In 2022, we published a journal article about our finding with the capable tool thus to simplify RootAsRole configuration [Wazan et al. 2022]. This article was more focused on the eBPF feature, and tool outputs analysis.

In 2023, we published a third article about explaining linux kernel issues [Billoir et al. 2023]. This article proposes enhancements to achieving a balance between usability and the principle of least privilege, emphasizing the need for precise capability definitions.

In May 2024, we published a more general article about the Administrative privilege on various OS [Billoir et al. 2024]. This article explores the different approaches implemented by the main operating systems (namely Linux, Windows, FreeBSD, and Solaris) to control the privileges of system administrators in order to enforce the principle of least privilege. We define a set of requirements to manage these privileges properly, striving to balance adherence to the principle of least privilege and usability. We also present a deep analysis of each administrative privilege system based on these requirements and exhibit their benefits and limitations.

In July 2024, we studied how to integrate RootAsRole on today's production environment as the project becomes a mature project. This article presents a semi-automated process that improves Ansible-based deployments to have fine-grained control on administrative privileges granted to Ansible tasks. This article is not yet published.

Comparison with sudo

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. You can configure our tool easily with chsr command. To find out which capability is needed for a administrative command, we provide the capable command. With these two tools, administrators could configure its system to respect the least privilege principle.

Scenarios

Scenario 1: Installing a new package

You are using your personal computer and you want to install a new package. By default, RootAsRole add one role with 2 tasks : one task for using chsr command that grant only the CAP_LINUX_IMMUTABLE capability as root user (unprivileged), and one task for all commands but without CAP_LINUX_IMMUTABLE privilege. As installing a package may require almost all capabilities, you can use the default role to install a package. Indeed, if you wish to install apache2, you'll need CAP_NET_BIND_SERVICE, if you install docker you'll need many privileges, virtualbox needs CAP_SYS_MODULE, etc. So, you can use the default role to install a package:

sr apt install <package>

Scenario 2: Granting users the right to restart their system

You are the system administrator of a company and you want to delegate the right to restart the server to a user. You can use chsr to create a role and grant the right to restart the server to users.

sr chsr role r_users add # Create a new role
sr chsr role r_users grant -g users # Grant the role to the group users
sr chsr role r_users task t_reboot add # Create a new task
sr chsr role r_users task t_reboot cmd whitelist add reboot # Add the reboot command to the task
sr chsr role r_users task t_reboot cred caps whitelist add CAP_SYS_BOOT # Add the CAP_SYS_BOOT capability to the task

Then users can restart the server with the following command:

sr reboot

Scenario 3 : Passing environment variables to a command

You are a developer and you want to pass environment variables to a command. For example with sudo you can use the -E option to pass environment variables to a command. With RootAsRole, you'll need to setup a role with a task that allows the command to use environment variables. However, as you keep the default configuration, you'll have two roles that matches ANY commands, and if the first one is more restrictive than the second one, you'll need to specify the role to use. Here is an example:

sr chsr role env add # Create a new role
sr chsr role env task env add # Create a new task
sr chsr role env task env cmd setpolicy allow-all # Add all command to the task
sr chsr role env task env cred caps setpolicy allow-all # Add all capabilities to the task
sr chsr role env task env o env setpolicy keep-all # Keep the environment variables

Then you can use the following command to pass environment variables to a command:

sr -r env [command]

This is because the default role do not keep the environment variables, so if you want to keep environment variables you need to specify the role to use.

Scenario 4 : Automating reboot every day

You are an administrator that want to automatically reboot the system at 04:05 every day with cron for example. You can disable authentication by setting skip-auth in the options. Here is an example:

sr chsr role auto add # Create a new role
sr chsr role grant -u cron # Grant the role to the user cron
sr chsr role auto task cron_reboot add # Create a new task
sr chsr role auto task cron_reboot cmd whitelist add reboot # Add the reboot command to the task
sr chsr role auto task cron_reboot cred caps whitelist add CAP_SYS_BOOT # Add the CAP_SYS_BOOT capability to the task
sr chsr role auto task cron_reboot o authentication skip # Skip authentication

Then you can configure the cron to reboot the system with the following command:

sr crontab -u cron -e

and add the following line to reboot the system at 04:05 every day

5 4 * * * sr -r auto -t cron_reboot reboot

Note: You should consider to set the -r auto -t cron_reboot options to the sr command when you automate a task to avoid any security issue or future conflict.

For a more complete example, you can checkout the Is a Linux system without root user possible ? section.

HISTORY

1.0.0 (August 2018)

RootAsRole initiated by SIERA IRIT CNRS research team with Ahmad Samer WASAN as owner of the proof of concept. It is presented for the first time at "Le capitole du libre" in Toulouse. A paper is published%%cite{wazanRootAsRoleSecureAlternative2021}.

2.0.0 (August 2019)

RootAsRole is still a proof of concept but now proposes an eBPF subprogram to obtain the capabilities of a generic command. A paper is published at Computer and Security%%cite{wazanRootAsRoleSecurityModule2022}.

3.0.0 (September 2024)

RootAsRole direction is delegated to Eddie BILLOIR, a SIERA PhD student that contributed to the project all along its courses. It is now entirely rewritten in Rust, the eBPF subprogram is now in a separate project called RootAsRole-capable. The project takes a new direction and aims to be production ready with a massive reconception of every tools, a new configuration file format and complete documentation.

Installation

Prerequisites

Install git

How to build

  1. git clone https://github.com/LeChatP/RootAsRole
  2. cd RootAsRole
  3. cargo xtask install -bip sudo
The installation process requires CAP_SETFCAP privileges and also grants full privileges to the user who installs, making them privileged by default.

What does the installation script do?

The installation script parameters explaination:

  • cargo xtask install -bip sudo
    • (-b) Builds the project
    • (-i) Installs necessary dependencies
    • (-p) Use the sudo command to perform administrative tasks

Install script does the following:

  • Dependency Step :
    • Installing necessary dependencies considering if compiling from source.
  • Build Step :
    • Building sr and chsr binaries
  • Install Step :
    • Copying sr and chsr binaries to /usr/bin
    • Setting all capabilities on /usr/bin/sr
    • Setting owners and permissions on /usr/bin/sr
  • Configuration Step :
    • Deploying /etc/pam.d/sr for PAM configuration
    • Deploying /etc/security/rootasrole.json for configuration
    • Setting immutable on /etc/security/rootasrole.json if filesytem supports it

What is sr tool

sr is the abbrevation of "switch role" is a command line tool like sudo. It allows a permitted user to execute a command as another user and groups. More than sudo it allows to a permitted user to obtain some privileges. The sr command is used to switch to a role.

Usage

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

Chsr tool documentation

Chsr is a command-line tool to configure roles, permissions and execution options. If you want to know how the file configuration works, you can check the file configuration section.

Usage

Usage: chsr [command] [options]

Commands:
  -h, --help                    Show help for commands and options.
  list, show, l                 List available items; use with specific commands for detailed views.
  role, r                       Manage roles and related operations.


Role Operations:
chsr role [role_name] [operation] [options]
  add, create                   Add a new role.
  del, delete, unset, d, rm     Delete a specified role.
  show, list, l                 Show details of a specified role (actors, tasks, all).
  purge                         Remove all items from a role (actors, tasks, all).
  
  grant                         Grant permissions to a user or group.
  revoke                        Revoke permissions from a user or group.
    -u, --user [user_name]      Specify a user for grant or revoke operations.
    -g, --group [nameA,...]     Specify one or more groups combinaison for grant or revoke operations.
Example : chsr role roleA grant -u userA -g groupA,groupB -g groupC
This command will grant roleA to "userA", "users that are in groupA AND groupB" and "groupC".



Task Operations:
chsr role [role_name] task [task_name] [operation]
  show, list, l                 Show task details (all, cmd, cred).
  purge                         Purge configurations or credentials of a task (all, cmd, cred).
  add, create                   Add a new task.
  del, delete, unset, d, rm     Remove a task.


Command Operations:
chsr role [role_name] task [task_name] command [cmd]
  show                          Show commands.
  setpolicy [policy]            Set policy for commands (allow-all, deny-all).
  whitelist, wl [listing]       Manage the whitelist for commands.
  blacklist, bl [listing]       Manage the blacklist for commands.


Credentials Operations:
chsr role [role_name] task [task_name] credentials [operation]
  show                          Show credentials.
  set, unset                    Set or unset credentials details.
     --setuid [user]            Specify the user to set.
     --setgid [group,...]       Specify groups to set.
  caps                          Manage capabilities for credentials.


Capabilities Operations:
chsr role [role_name] task [task_name] credentials caps [operation]
  setpolicy [policy]            Set policy for capabilities (allow-all, deny-all).
  whitelist, wl [listing]       Manage whitelist for credentials.
  blacklist, bl [listing]       Manage blacklist for credentials.


Options:
chsr options [option] [operation]
chsr role [role_name] options [option] [operation]
chsr role [role_name] task [task_name] options [option] [operation]
  path                          Manage path settings (set, whitelist, blacklist).
  env                           Manage environment variable settings (set, whitelist, blacklist, checklist).
  root [policy]                 Defines when the root user (uid == 0) gets his privileges by default. (privileged, user, inherit)
  bounding [policy]             Defines when dropped capabilities are permanently removed in the instantiated process. (strict, ignore, inherit)
  wildcard-denied               Manage chars that are denied in binary path.
  timeout                       Manage timeout settings (set, unset).


Path options:
chsr options path [operation]
  setpolicy [policy]            Specify the policy for path settings (delete-all, keep-safe, keep-unsafe, inherit).
  set [path]                    Set the policy as delete-all and the path to enforce.
  whitelist, wl [listing]       Manage the whitelist for path settings.
  blacklist, bl [listing]       Manage the blacklist for path settings.


Environment options:
chsr options env [operation]
  setpolicy [policy]            Specify the policy for environment settings (delete-all, keep-all, inherit).
  set [key=value,...]           Set variables to enforce.
  keep-only [key,...]           Set the policy as delete-all and the key map to keep.
  delete-only [key,...]         Set the policy as keep-all and the key map to delete.
  whitelist, wl [listing]       Manage the whitelist for environment settings.
  blacklist, bl [listing]       Manage the blacklist for environment settings.
  checklist, cl [listing]       Manage the checklist for environment settings. (Removed if contains unsafe chars)
  setlist, sl [listing]         Manage the setlist for environment settings. (define environment variables) 

Timeout options:
chsr options timeout [operation]
  set, unset                    Set or unset timeout settings.
    --type [tty, ppid, uid]     Specify the type of timeout.
    --duration [HH:MM:SS]       Specify the duration of the timeout.
    --max-usage [number]        Specify the maximum usage of the timeout.

Listing:
    add [items,...]                        Add items to the list.
    del [items,...]                        Remove items from the list.
    set [items,...]                        Set items in the list.
    purge                                  Remove all items from the list.

Capable tool usage

Usage: capable [OPTIONS] [COMMAND]...

Arguments:
  [COMMAND]...  Specify a command to execute with arguments

Options:
  -s, --sleep   Specify a delay before killing the process
  -d, --daemon         collecting data on system and print result at the end
  -j, --json           Print output in JSON format, ignore stdin/out/err
  -h, --help           Print help (see more with '--help')

Examples

$ capable -j cat /etc/shadow
["CAP_DAC_OVERRIDE","CAP_DAC_READ_SEARCH"]

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.

  2. 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.

  3. 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.

  4. 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.

Why you need to use Linux Capabilities

Linux capabilities are a way to give specific privileges to a process without giving it full root access. This is useful when you want to give a process the ability to do something that requires root privileges, but you don't want to change user. For example, you might want to give a process the ability to bind to a privileged port (ports below 1024), but you don't want become root user or get other privileges.

How Linux Capabilities work

Linux capabilities are a way to split the privileges of the root user into a set of distinct capabilities. Each capability is a specific privilege that can be granted to a process. For example, the CAP_NET_BIND_SERVICE capability allows a process to bind to a privileged port.

You can find more information about Linux capabilities in the capabilities(7)

What is Role-Based Access Control Model?

Role-Based Access Control (RBAC) is a access control model that grants access to resources based on a user's role within an organization [Ferraiolo et al. 2001]. This model makes it easier to manage user-centric access control policies. Indeed, this design allows to simply the distribution of user's responsibilities and better organize the access control policies in this context.

What about Attribute-based Access Control Model ?

Attribute-Based Access Control (ABAC) is a more flexible model that grants access based on attributes of the user, the resource, the actions, and the environment by applying constraints on them. This design allows to implement generic access control policies. However, ABAC does not solve the problem of managing user-centric responsibilities access control policies. Indeed, ABAC allow to define generic policies, but not to manage them correctly given specific access control need. However, As ABAC can define a generic policy, it can be used to implement RBAC [Jin et al. 2012], Bell-Lapadula (for confidentiality) [Balamurugan et al. 2015] or even Biba (for integrity) access control models [Kashmar et al. 2020].

So ABAC is allowing to reach multiple access control properties by implementing multiple specific access control models. However, not respecting precisely these models designs may not reach the expected security properties.

So why not use ABAC instead of RBAC for RootAsRole?

RootAsRole wants to delegate administrative responsibilities to severals users with more respect on the principle of least privilege. This means that RootAsRole access control policy is more user-centric, and thus, RBAC is more adapted to this context.

Is it possible to use ABAC with RootAsRole?

Today, it requires some development to integrate RootAsRole in an ABAC implementation. However, RootAsRole will never implement ABAC by itself, so RootAsRole would requires to implement RBAC (with RootAsRole information) in the ABAC solution.

Static/Dynamic Separation of Duties notion

Static Separation of Duties

Static Separation of Duties (SSD) within an RBAC ensures that no single user can hold conflicting administrative roles, enhancing security and operational integrity[Ferraiolo et al. 2001]. For instance, SSD policies would prevent a user assigned as a "System Administrator" from also being a "Network Administrator" or "Backup Administrator," thereby mitigating the risk of entire control of a system and potential fraud.

With RootAsRole, you can implement SSD by creating roles that are mutually exclusive by adding ssd array in a role definition. For example, you can create a role for a "System Administrator" and another for a "Network Administrator." You can then assign these roles to different users, ensuring that no single user has both roles at the same time. If a user obtains a new role that conflicts with an existing role, RootAsRole will prevent the user to use any conflicting role.

Dynamic Separation of Duties

Dynamic Separation of Duties (DSD) in RBAC ensures that no single user can perform conflicting roles within a system simultaneously, managed at runtime. It verifies users' or system sessions context before allowing them to activate roles, ensuring that they do not have conflicting permissions given the dynamic context of the system.

For example, In a very small business, it may have only one system administrator. In this case the small business can enforce a DSD feature that prevent the unique administrator to simultaneously activate roles that allow both system configuration and audit log management, and cannot perform system configuration if no audit is enforced, ensuring that the administrator cannot cover his tracks.

For now, RootAsRole does not support DSD.

How does work role hierarchy feature

A role hierarchy allows roles to be organized in a tree-like structure where roles can inherit permissions from other roles. This means that a higher-level role, often called a parent role, can pass down its permissions to lower-level roles, known as child roles. For example, in a corporate environment, a role hierarchy might be set up so that a "Manager" role inherits all the permissions of an "Employee" role, plus additional managerial permissions. This hierarchical structuring simplifies the assignment and management of permissions because changes to a parent role automatically propagate to its child roles, reducing redundancy and the potential for errors. In RootAsRole this is possible by adding the parent array in a role definition.

RootAsRole Command matching

Role Conflict resolution

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 [Abedin et al. 2006] 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 :
    1. exact command is more precise than command with regex argument
    2. command with regex argument is more precise than a wildcarded command path
    3. wildcarded command path is more precise than wildcarded command path and regex args
    4. wildcarded command path and regex args is more precise than complete wildcard
    5. A task granting no capability is less privileged than one granting at least one capability
    6. A task granting no insecure capability is less privileged than one at least one insecure capability
    7. A task granting insecure capability is less privileged than one granting all capabilities.
    8. A task without setuid is less privileged than one has setuid.
    9. if no root is disabled, a task without 'root' setuid is less privileged than a task with 'root' setuid
    10. A task without setgid is less privileged than one has setgid.
    11. A task with a single setgid is less privileged than one that set multiple gid.
    12. if no root is disabled, A task with multiple setgid is less privileged than one that set root gid
    13. if no root is disabled, A task with root setgid is less privileged than one that set multiple gid, particularly using root group
    14. A task that requires authentication is less privileged than one that doesn't
    15. A task that keeps safe PATH values is less privileged than one that doesn't
    16. A task that keeps unsafe PATH values is less privileged than one that keep it safe
    17. A task that keeps environment variables is less privileged than one that doesn't
    18. A task that enables root privileges is less privileged than one which disables root privileges (see "no-root" feature)
    19. A task that disables the Bounding set feature in RootAsRole is less privileged than one that enables it
    20. user assignment is more precise than the combination of group assignment
    21. the combination of group assignment is more precise than single group assignment

After these step, if two roles are conflicting, these roles are considered equal. In this case if execution settings are totally equal, no matter which role is chosen, it execute the asked command. If execution settings are different, there is a conflict, 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 or/and --task option). In such cases, we highly recommend to review the design of the configured access control.

What is eBPF ?

eBPF (extended Berkeley Packet Filter) [Sharaf et al. 2022] is a technology that allows the execution of custom programs in the Linux kernel without changing the kernel source code or loading kernel modules. In RootAsRole, we use eBPF to implement the capable command. This command allows you to check if a process requests any capability.

Is a Linux system without root user possible ?

To make it short, not really. But you can design your system to never have to use the root user. This is what RootAsRole aims, and the exact purpose of Linux Capabilities. Let's consider you want a system without root user and you want to setup a webserver. Firstly, let's create the apache2 user and group:

sr adduser apache2

We consider that we still use the default configuration of RootAsRole. Then, let's add a task to install apache2 with the apache2 user:

sr chsr r r_root t install_apache2 add
sr chsr r r_root t install_apache2 cmd whitelist add apt install apache2
sr chsr r r_root t install_apache2 cmd whitelist add "apt upgrade( -y)? apache2"
sr chsr r r_root t install_apache2 cred set --caps CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_NET_BIND_SERVICE,CAP_SETUID --setuid apache2 --setgid apache2

Then, let's add a task to start apache2 with the apache2 user:

sr chsr r r_root t start_apache2 add
sr chsr r r_root t start_apache2 cmd whitelist add "systemctl ((re)?start|stop) apache2"
sr chsr r r_root t start_apache2 cmd whitelist add "service apache2 ((re)?start|stop)"
sr chsr r r_root t install_apache2 cred set --caps CAP_NET_BIND_SERVICE,CAP_SETUID --setuid apache2 --setgid apache2

So now you can install and start apache2 with the apache2 user:

sr apt install apache2

This should install apache2 configuration files owned by apache2 user and group. Then you can start apache2 with the apache2 user:

sr systemctl start apache2

How does configuration work?

The configuration is stored in a JSON file. The default path is /etc/security/rootasrole.json. It is possible to change the path where the configuration is stored by changing the path setting in the configuration file manually. Note: The configuration file must be immutable after edition.

"storage": {
  "method": "json",
  "settings": {
    "path": "/etc/security/rootasrole.json",
    "immutable": true
  }
}

Next, the configuration is divided into roles, tasks, commands, credentials, and options. Each role can have multiple tasks, each task can have multiple commands and credentials. The options are global and can be set for the whole configuration or for a specific role or task.

How configuration work with examples

A complete Config example

The following example shows a RootAsRole config without plugins when almost every field is modified with comments.

{
  "version": "3.0.0-alpha.4", // Version of the configuration file
  "storage": { // Storage settings, where the Roles and Execution options are stored
    "method": "json", // Storage method
    "settings": { // Storage settings
      "immutable": false, // Program return error if the file is not immutable, default is true
      "path": "target/rootasrole.json" // Path to the storage file
    }
  },
  "options": {
    "path": { // Path options
      "default": "delete", // Default policy for path, delete-all, keep-safe, keep-unsafe, inherit
      "add": [ // Paths to add to the whitelist
        "path1",
        "path2"
      ],
      "sub": [ // Paths to remove from the whitelist
        "path3",
        "path4"
      ]
    },
    "env": { // Environment options
      "default": "delete", // Default policy for environment, delete-all, keep-all, inherit
      "keep": [ // Environment variables to keep
        "env1",
        "env2"
      ],
      "check": [ // Environment variables to check for unsafe characters
        "env3",
        "env4"
      ],
      "delete": [ // Environment variables to delete
        "env5",
        "env6"
      ]
    },
    "root": "privileged", // Default policy for root, privileged, user, inherit
    "bounding": "ignore", // Default policy for bounding, strict, ignore, inherit
    "wildcard-denied": "*", // Characters denied in any binary path
    "timeout": {
      "type": "ppid", // Type of timeout, tty, ppid, uid
      "duration": "15:30:30", // Duration of the timeout
      "max_usage": 1 // Maximum usage before timeout expires
    }
  },
  "roles": [ // Role list
    {
      "name": "complete", // Role name
      "actors": [ // Actors granted
        {
          "id": 0, // ID of the actor, could be a name
          "type": "user" // Type of actor, user, group
        },
        {
          "groups": 0, // ID of the group, could be a name
          "type": "group" 
        },
        {
          "type": "group",
          "groups": [ // List of groups, this is an AND condition between groups
            "groupA",
            "groupB"
          ]
        }
      ],
      "tasks": [ // List of role's tasks
        {
          "name": "t_complete", // Task name, must be unique in the role
          "purpose": "complete", // Task purpose, just a description
          "cred": {
            "setuid": "user1", // User to setuid before executing the command
            "setgid": [ // Groups to setgid before executing the command, The first one is the primary group
              "group1",
              "group2"
            ],
            "capabilities": { // Capabilities to grants
              "default": "all", // Default policy for capabilities, all, none
              "add": [ // Capabilities to add
                "CAP_LINUX_IMMUTABLE",
                "CAP_NET_BIND_SERVICE"
              ],
              "sub": [ // Capabilities to remove, overrides add
                "CAP_SYS_ADMIN",
                "CAP_SYS_BOOT"
              ]
            }
          },
          "commands": {
            "default": "all", // Default policy for commands, allow-all, deny-all
            "add": [ // Commands to add to the whitelist
              "ls",
              "echo"
            ],
            "sub": [ // Commands to add to the blacklist
              "cat",
              "grep"
            ]
          },
          "options": { // Task-level options
            "path": {
              "default": "delete", // When default is not inherit, all upper level options are ignored
              "add": [
                "path1",
                "path2"
              ],
              "sub": [
                "path3",
                "path4"
              ]
            },
            "env": {
              "default": "delete",
              "keep": [
                "env1",
                "env2"
              ],
              "check": [
                "env3",
                "env4"
              ],
              "delete": [
                "env5",
                "env6"
              ]
            },
            "root": "privileged",
            "bounding": "ignore",
            "wildcard-denied": "*",
            "timeout": {
              "type": "ppid",
              "duration": "15:30:30",
              "max_usage": 1
            }
          }
        }
      ],
      "options": { // Role-level options
        "path": {
          "default": "delete",
          "add": [
            "path1",
            "path2"
          ],
          "sub": [
            "path3",
            "path4"
          ]
        },
        "env": {
          "default": "delete",
          "keep": [
            "env1",
            "env2"
          ],
          "check": [
            "env3",
            "env4"
          ],
          "delete": [
            "env5",
            "env6"
          ]
        },
        "root": "privileged",
        "bounding": "ignore",
        "wildcard-denied": "*",
        "timeout": {
          "type": "ppid",
          "duration": "15:30:30",
          "max_usage": 1
        }
      }
    }
  ]
}

Config example Role hierarchy plugin

The following example shows a RootAsRole config using role hierarchy plugin.

{
  "version": "3.0.0-alpha.4",
  "roles": [
    {
      "parents": ["user"],
      "name": "admin",
      "actors": [
        {
          "id": 0,
          "type": "user"
        }
      ],
      "tasks": [
      ],
    },
    {
      "name": "user",
      "actors": [
        {
          "id": 1,
          "type": "user"
        }
      ],
      "tasks": [
        {
          "name": "t_user",
          "purpose": "user",
          "commands": {
            "default": "all",
            "sub": [
              "cat",
              "grep"
            ]
          }
        }
      ]
    }
  ]
}

In this example, the admin role inherits from the user role. The user role has a task t_user that denies cat and grep commands. The admin role will inherit the t_user task and deny cat and grep commands.

Config example Static separation of duties plugin

The following example shows a RootAsRole config using separation of duties plugin.

{
  "version": "3.0.0-alpha.4",
  "roles": [
    {
      "ssd": ["user"],
      "name": "admin",
      "actors": [
        {
          "id": 0,
          "type": "user"
        }
      ],
      "tasks": [
      ],
    },
    {
      "name": "user",
      "actors": [
        {
          "id": 0,
          "type": "user"
        }
      ],
      "tasks": [
        {
          "name": "t_user",
          "purpose": "user",
          "commands": {
            "default": "all",
            "sub": [
              "cat",
              "grep"
            ]
          }
        }
      ]
    }
  ]
}

In this example, the admin role is separated from the user role. The user 0 cannot be in the user role and the admin role at the same time. But currently this user is still on these two roles. In resulting, the user 0 will not be able to execute any admin or user role's tasks.

Config example with hashchecker plugin

Hashchecker plugin verifies the integrity of the binary before executing it. The following example shows a RootAsRole config using hashchecker plugin.

{
  "version": "3.0.0-alpha.4",
  "roles": [
    {
      "name": "admin",
      "actors": [
        {
          "id": 0,
          "type": "user"
        }
      ],
      "tasks": [
        {
          "name": "t_admin",
          "purpose": "admin",
          "commands": {
            "default": "none",
            "add": [
              {
                "command": "/usr/bin/cat superfile",
                "hash_type": "sha256",
                "hash": "3b77deacba25588129debfb3b9603d7e7187c29d7f6c14bdb667426b7be91761"
              }
            ]
          }
        }
      ]
    }
  ]
}

This example shows a t_admin task that allows the cat superfile command only if the hash of the binary is 3b77deacba25588129debfb3b9603d7e7187c29d7f6c14bdb667426b7be91761. If the hash of the binary is different, the command isn't even considered in configuration setup. Supported hashes : SHA224, SHA256, SHA384, SHA512.

How options work with examples

Path options example 1

Here is an example global configuration:

{
  "options": {
    "path": {
      "default": "delete-all",
      "add": [
        "/usr/bin"
      ]
    }
  }
}

This configuration will delete all paths and add /usr/bin to the whitelist.

{
  "options": {
    "path": {
      "default": "delete-all",
      "add": [
        "/usr/bin"
      ]
    }
  },
  "roles": {
    "admin": {
      "options": {
        "path": {
          "default": "inherit",
          "add": [
            "/usr/sbin"
          ]
        }
      }
    }
  }
}

This configuration will delete all paths and add /usr/bin to the whitelist for all roles. The admin role will inherit the global configuration and add /usr/sbin to the whitelist. So the final configuration for the admin role will be /usr/bin:/usr/sbin.

Path options example 2

Here is an example global configuration:

{
  "options": {
    "path": {
      "default": "keep-safe",
      "add": [
        "/usr/bin"
      ]
    }
  }
}

This configuration will keep all paths that are absolute and add /usr/bin to the path.

{
  "options": {
    "path": {
      "default": "keep-safe",
      "add": [
        "/usr/bin"
      ]
    }
  },
  "roles": {
    "admin": {
      "options": {
        "path": {
          "default": "inherit",
          "add": [
            "/usr/sbin"
          ]
        }
      }
    }
  }
}

This configuration will keep all paths that are absolute and add /usr/bin to the whitelist for all roles. The admin role will inherit the global configuration and add /usr/sbin to the whitelist. So the final configuration for the admin role will be /usr/bin:/usr/sbin:$PATH, where $PATH is the current executor path value.

Path options example 3

Here is an example global configuration:

{
  "options": {
    "path": {
      "default": "keep-unsafe",
      "sub": [
        "/usr/bin"
      ]
    }
  }
}

This configuration will keep all paths, even them that are relative, and remove /usr/bin from the path.

{
  "options": {
    "path": {
      "default": "keep-unsafe",
      "add": [
        "/usr/bin"
      ]
    }
  },
  "roles": {
    "admin": {
      "options": {
        "path": {
          "default": "inherit",
          "add": [
            "/usr/sbin"
          ]
        }
      }
    }
  }
}

This configuration will keep all paths, even them that are relative, and add /usr/bin to the whitelist for all roles. The admin role will inherit the global configuration and add /usr/sbin to the whitelist. So the final configuration for the admin role will be /usr/bin:/usr/sbin:$PATH, where $PATH is the current executor path value.

Note: path are always prepended to the current path value.

Path options example 4

Here is an example global configuration:

{
  "options": {
    "path": {
      "default": "inherit",
      "add": [
        "/usr/bin"
      ]
    }
  }
}

If the policy is inherit in global configuration, the policy will be delete-all.

{
  "options": {
    "path": {
      "default": "delete-all",
      "add": [
        "/usr/bin"
      ]
    }
  },
  "roles": {
    "admin": {
      "options": {
        "path": {
          "default": "keep-safe",
          "sub": [
            "/usr/sbin"
          ]
        }
      },
      "tasks": {
        "task1": {
          "options": {
            "path": {
              "default": "inherit",
              "add": [
                "/usr/sbin"
              ]
            }
          }
        }
      }
    }
  }
}

This complex configuration will delete-all paths in the global configuration for all roles except for admin role. The admin role will keep all paths that are absolute and remove /usr/sbin from the path. The task1 task will inherit the admin role configuration and tries to add /usr/sbin to the path but it will be ignored because the task inherits the admin role configuration, and it removes /usr/sbin from the path. So the final path is the current executor path value less /usr/sbin.

In conclusion, two logical properties can be deducted :

  1. The path removed from the path variable cannot be added, even by inheritance.
  2. When a more precise configuration defines a policy (delete-all,keep-safe,keep-unsafe), it will override less precise configuration.
    • Global is less precise than Role, Role is less precise than Task

Environment options example 1

Here is an example global configuration:

{
  "options": {
    "env": {
      "default": "delete",
      "keep": [
        "VAR1"
      ]
    }
  }
}

Environment variables are managed in the same way as paths. The policy can be delete, keep, or inherit. The delete policy will remove all environment variables except the ones in the keep list. The keep list is a list of environment variables that will be kept in the environment.

{
  "options": {
    "env": {
      "default": "delete",
      "keep": [
        "VAR1"
      ]
    }
  },
  "roles": {
    "admin": {
      "options": {
        "env": {
          "default": "inherit",
          "keep": [
            "VAR2"
          ]
        }
      }
    }
  }
}

This configuration will delete all environment variables except VAR1 for all roles. The admin role will inherit the global configuration and keep VAR2 in the environment. So only VAR1 and VAR2 values will be kept in the environment for the admin role.

Environment options example 2

Here is an example global configuration:

{
  "options": {
    "env": {
      "default": "keep",
      "delete": [
        "VAR1"
      ]
    }
  }
}

The delete list is a list of environment variables that will be removed from the environment.

{
  "options": {
    "env": {
      "policy": "keep",
      "delete": [
        "VAR1"
      ]
    }
  },
  "roles": {
    "admin": {
      "options": {
        "env": {
          "policy": "inherit",
          "delete": [
            "VAR2"
          ]
        }
      }
    }
  }
}

This configuration will keep all environment variables except VAR1 for all roles. The admin role will inherit the global configuration and remove VAR2 from the environment. So only VAR1 and VAR2 values are removed from the environment for the admin role.

Environment options example 3

Here is an example global configuration:

{
  "options": {
    "env": {
      "default": "keep",
      "check": [
        "VAR1"
      ]
    }
  }
}

The check list is a list of environment variables that will be checked for unsafe characters. If an environment variable contains unsafe characters, it will be removed from the environment.

What does Continuous Integration mean?

Continuous Integration (CI) is a software development practice where developers regularly merge their code changes into a central repository, after which automated builds and tests are run. The key goals of CI are to find and address bugs quicker, improve software quality, and reduce the time it takes to validate and release new software updates.

What is implemented in RootAsRole?

In RootAsRole, we use GitHub Actions to automate the CI process. We have defined a workflow that runs on every push to the main branch. This workflow consists of testing the code, building the project.

Contributing to RootAsRole

First off, thanks for taking the time to contribute! ❤️

All types of contributions are encouraged and valued. See the Table of Contents for different ways to help and details about how this project handles them. Please make sure to read the relevant section before making your contribution. It will make it a lot easier for us maintainers and smooth out the experience for all involved. The community looks forward to your contributions. 🎉

And if you like the project, but just don't have time to contribute, that's fine. There are other easy ways to support the project and show your appreciation, which we would also be very happy about:

  • Star the project
  • Tweet about it
  • Refer this project in your project's readme
  • Mention the project at local meetups and tell your friends/colleagues

Table of Contents

Code of Conduct

This project and everyone participating in it is governed by the RootAsRole Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to .

I Have a Question

If you want to ask a question, we assume that you have read the available Documentation.

Before you ask a question, it is best to search for existing Issues that might help you. In case you have found a suitable issue and still need clarification, you can write your question in this issue. It is also advisable to search the internet for answers first.

If you then still feel the need to ask a question and need clarification, we recommend the following:

  • Open an Issue.
  • Provide as much context as you can about what you're running into.
  • Provide project and platform versions (nodejs, npm, etc), depending on what seems relevant.

We will then take care of the issue as soon as possible.

I Want To Contribute

When contributing to this project, you must agree that you have authored 100% of the content, that you have the necessary rights to the content and that the content you contribute may be provided under the project license.

Reporting Bugs

Before Submitting a Bug Report

A good bug report shouldn't leave others needing to chase you up for more information. Therefore, we ask you to investigate carefully, collect information and describe the issue in detail in your report. Please complete the following steps in advance to help us fix any potential bug as fast as possible.

  • Make sure that you are using the latest version.
  • Determine if your bug is really a bug and not an error on your side e.g. using incompatible environment components/versions (Make sure that you have read the documentation. If you are looking for support, you might want to check this section).
  • To see if other users have experienced (and potentially already solved) the same issue you are having, check if there is not already a bug report existing for your bug or error in the bug tracker.
  • Also make sure to search the internet (including Stack Overflow) to see if users outside of the GitHub community have discussed the issue.
  • Collect information about the bug:
  • Stack trace (Traceback)
  • OS, Platform and Version (Ubuntu 20.04, Debian 10, RedHat 8, etc.)
  • Version of the interpreter, compiler, SDK, runtime environment, package manager, depending on what seems relevant.
  • Possibly your input and the output
  • Can you reliably reproduce the issue? And can you also reproduce it with older versions?

How Do I Submit a Good Bug Report?

You must never report security related issues, vulnerabilities or bugs including sensitive information to the issue tracker, or elsewhere in public. Instead sensitive bugs must be sent by email to lechatp@outlook.fr using the PGP key below

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBGN3U8UBEADbe0Wm75Ouew0WIIveLae8tWltIEvKr7rbCse8EHpDbWlESrGu
tWo5SdIHDUu16YZyih1BrGRQ3AXnPJG/wmWP1Pz+vyMvwaHN0WWzhZS6b/24v0ai
yLAXQUQCE02haTsn5mj8aMFP2dUhMQYsEYgjPcOJYhm5udxXJeYQAeZTcUnKjrji
ECR3VErfjjW0SFsI4YkqhFpeOCcXhUR38NszpXPUZ9WcEgsvGB8N8nPqscEYQngI
Xkk0WvJhkVmJk5NlPTUyhxhuxz7h4ADuYTnmbk5gZK3HKpmDXMVz0fQik6YKUNFv
UowYA+QhLI892j62HTcBuCc8x9DB0kKTH/nuRjPYnX8tKyOPhgq9NKkOxSC4dOe9
gTogSdhVA6TZvnbpssvBSz6WPYeIm/jfJdCEMbih2CteireTuyYLMCK2zstKFnnN
GBrUVdFGdXwuxM5TJB5LotLQ/E/xxstGphGaHi+gKRLSiKV7wlFEhlgWB2l8RuWo
F9KSOTm81mqCsMF6D4+on72uJV52Tumomc4eU8ESodHAsSiR9QkZ55BnnLu+Y8Wg
b/axlTI1j2UV1ABxrqaxpb4V/z2DQNtnM/vNhuDi0maXHrUDHQRehwvTn/4mGsbA
zXUMfOrFqCnh2QXXoCUSOVlgb2quLEJ2xQqr1j01yccPY/8iOC9I/0R0vwARAQAB
tBxMZUNoYXRQIDxsZWNoYXRwQG91dGxvb2suZnI+iQJNBBMBCAA3FiEEdPQ8V3S+
HzUn3vpINcFV6gUlEE0FAmN3U8cFCQWjmoACGwMECwkIBwUVCAkKCwUWAgMBAAAK
CRA1wVXqBSUQTffYD/0Qi/WephoN7JjLEYMID2mBFfdE4Lz6uHjhSEcLAKIrEZF3
VaNQa7sTug94j9Rkjdk6/GBk3SwHTAtRiTyw+ReNOW5LH3SbUO/we7quexPhZDON
NbeJmCUX811okJL2av/52swE+MPYJNbn4BX3lWSzgN5fQZ9I/0QUm2yQnjq5vxar
vbP144GW+ni9MvFYfcYZ6hSRpEhFlbJTJsJAZS4lTxkevg5ZdoIvMo63ZJ3CHTuN
EfXmPvYxtKvo9h9ESQbMV2A++LDq4/JdBfBSQrXFJq8XL+75aQ7QkakiGp72DwTQ
ds/MtAXe/3G2tjt7b/ytcNW4C8yPYiCbYdjBkS7aKIRF1XbRsgpARdOfCKsN/9Gu
iIb/Oy2XqwLq0xTgl9wS9XldSX7sNVyM1DDRm6t1/cLWmqZCroApoIWpQX4SznRe
3QCZ44eTHq+6b+eSiQZyrqaNDyVUdmXCTrQqXiotI7qQ00Hjigv6K2MInKGaN9Dw
/nfGxBD3KJOVnTYzSTacB5vbS3NQv0nKBtg3wjaE5/l7Cq6ZQmd4SgGYX3F5wuuz
jGtBmxe7gcZJzmodBLFflSbo0OFDmERcXyUls8jSEnbzRy8OVP2C2YOvXtxoL86g
pq2pA+HJRzP6oso2EwXdE8HxBLoZ1tu2vgKv6xduEmkw14cvSeoVzrm8aWxXf7kC
DQRjd1PHARAA14voBlK6KAaQ2oz+i1e9tiEUFFn5ZXxFdS4uH30Bttidugl1Ccdy
AeTCSrG5WU/zPilttjjHG+KCBxdFGCVV+r7xYAtuVFfasKVSJyGqDZN6nI9MdKMA
s3k7t9oz8RVvKWRpnLaxElvrE+k0n38t5LWQAyVrDeBQD0k0yneVZIc6OSaqANV6
nuy4Z0LWsoC8EIfjIQ+Swx/OrhluwSMObChIh1QU6tZ+S6pp2mZl4hHlRnEA9Ivz
LOZ2nB4IQ2SJL5jo5l9wFmzEseAsQPlSDowNNdPGik2b00UWfuMdM4BYjG140og9
5FW87c0LzSYQZ66rmQqOb6c9tAMzjvaeCaaeFW8vIQP3/C1MXYiiLCFKTLg1vG9b
sasT5nQVmq9ADjXf5uFk6UNKuXf0foUK5m8FTV5uvaZebekDPRUaEcuj8HSUaoER
TIR59k5rm4Ha9/ZJTspAtv1pyCU/MwLPAWXc1e7Tl0yvnJz6s2/RB88YWd95YfN/
h3pgKk8RaGkVKFv4bns7SIT4Ni4qxI1vqx07+t2CRQQOiqd9yXehAOsssQCI/p4a
CIBjeeDxGjqpH6Nho5TlXywvzb50vez6b7P5F2iW5/owqEBn8Rz+LqUeUia9ChAT
b7AAUeXeBhSq/xC8l3+bstvmTpcjW0kWLn+yovwTJCgB/eR7xALchPsAEQEAAYkC
PAQYAQgAJhYhBHT0PFd0vh81J976SDXBVeoFJRBNBQJjd1PIBQkFo5qAAhsMAAoJ
EDXBVeoFJRBNspQQAJK0m4gw3lFv0Vj3q5nIr8HcBn6L995BQwqvVrzAP/Bjl1xH
s1YmBZoU6zydQybMP6lkh0STwXtzOlTsUxh454vrUp/CzB+Q6mJvXSCyN8gYZiqz
q4GRNFx2Qppbui6Y+aMXoCtBv410wFxdE0U7i/+ZSf4U6cOi3y34QtBkicRdfPe/
hb6pe8WAqfzdkv+20lC/aM9sPjdM9r9/KYU6JPZ2knG9T4IJHMXEoxuk/TDZgM5P
Hl8pAY2LqN4ctbEclN0Z907baLkPBQDdbr38lD2H1isXsEZZxVuk8yoFOHyv2ey0
amf60BVX/kZgAUO+8v+eMXM+TrQJlRVOj0Jk0qL5HUJZ1yfE1Dzv4OwrVdkGI5e4
HGu7UgViAT5nQE7ATn7yoH31I00CWDfD1LPXrDsQeFsSYOJdfNFao+yPAYvE8XXL
AIWocEDRE1ANDJ0rNclgpn4kUtvqbYqdWxW97Ba5+6d9dHFc4CnXHHv6WFoEFTCH
RGufVgK54ynTLWi87jPoC371KOW3abjoWcsr5m57C2cil9nimjSTID+5w5zWXHip
0hp8q7N1rChsvkmoU5ZFnF8QjmbLOM2VFIW7hnT5WfXWkSOJLjCExEQuYJEcL7YC
nfacdGU6XXuJGhgFXCP7BYVQ5e8PlUowe/92T2NSPC7ZGCW0nsa3hH9wr8Jz
=K6/W
-----END PGP PUBLIC KEY BLOCK-----

We use GitHub issues to track bugs and errors. If you run into an issue with the project:

  • Open an Issue. (Since we can't be sure at this point whether it is a bug or not, we ask you not to talk about a bug yet and not to label the issue.)
  • Explain the behavior you would expect and the actual behavior.
  • Please provide as much context as possible and describe the reproduction steps that someone else can follow to recreate the issue on their own. This usually includes your code. For good bug reports you should isolate the problem and create a reduced test case.
  • Provide the information you collected in the previous section.

Once it's filed:

  • The project team will label the issue accordingly.
  • A team member will try to reproduce the issue with your provided steps. If there are no reproduction steps or no obvious way to reproduce the issue, the team will ask you for those steps and mark the issue as needs-repro. Bugs with the needs-repro tag will not be addressed until they are reproduced.
  • If the team is able to reproduce the issue, it will be marked needs-fix, as well as possibly other tags (such as critical), and the issue will be left to be implemented by someone.

Suggesting Enhancements

This section guides you through submitting an enhancement suggestion for RootAsRole, including completely new features and minor improvements to existing functionality. Following these guidelines will help maintainers and the community to understand your suggestion and find related suggestions.

Before Submitting an Enhancement

  • Make sure that you are using the latest version.
  • Read the documentation carefully and find out if the functionality is already covered, maybe by an individual configuration.
  • Perform a search to see if the enhancement has already been suggested. If it has, add a comment to the existing issue instead of opening a new one.
  • Find out whether your idea fits with the scope and aims of the project. It's up to you to make a strong case to convince the project's developers of the merits of this feature. Keep in mind that we want features that will be useful to the majority of our users and not just a small subset. If you're just targeting a minority of users, consider writing an add-on/plugin library.

How Do I Submit a Good Enhancement Suggestion?

Enhancement suggestions are tracked as GitHub issues.

  • Use a clear and descriptive title for the issue to identify the suggestion.
  • Provide a step-by-step description of the suggested enhancement in as many details as possible.
  • Describe the current behavior and explain which behavior you expected to see instead and why. At this point you can also tell which alternatives do not work for you.
  • Explain why this enhancement would be useful to most RootAsRole users. You may also want to point out the other projects that solved it better and which could serve as inspiration.

Your First Code Contribution

Improving The Documentation

The documentation needs to be improved. If you find a typo, error, or something that is not clear, please help us by correcting it. If you have a suggestion for improving the documentation, please follow the steps below:

  • Open an Issue
  • If you want to make the change yourself, fork the repository and make the changes in your fork. Then open a pull request with the changes. We will review the changes and merge them if they are good.

Attribution

This guide is based on the contributing-gen. Make your own!

FAQ

This page contains known issues and solutions for RootAsRole project.

capable does not work on my OS, what can I do ?

capable is a tool based on eBPF features, so it requires a Linux kernel version 4.1 or later. Additionnally you need many kernel features enabled, described here. It is also, possible that the program cannot allocate memory, in this case you may consider to add CAP_SYS_RESOURCE capability to the program, but this may not solve completely the issue.

Finally, if you want that capable works on your OS, you can 1) open an issue on the GitHub repository, 2) create a Vagrantfile in test/capable/ directory and a script to reproduce the issue/and or fix the problem. Note: Community Vagrant images may create more issues than they solve. For example, I never managed to make capable work on ArchLinux images, but my development machine is an ArchLinux.

Why capable do not show expected capabilities ?

Many reasons can explain that capable does not show expected capabilities. Here are some of them:

  1. You access to files that matches with ACLs, so you do not need any capabilities to access to restricted files. This case is better than granting CAP_DAC_OVERRIDE to the program.
  2. The program exit before the capabilities are requested. In this case, you may consider granting the blocking capability to the program.
  3. The program checks uid == 0. In this case, you may consider to change to root user. capable may misbehave when working as the root user. I am still investigating this issue.

Code of Conduct - RootAsRole

Our Pledge

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

Our Standards

Examples of behavior that contributes to a positive environment for our community include:

  • Demonstrating empathy and kindness toward other people
  • Being respectful of differing opinions, viewpoints, and experiences
  • Giving and gracefully accepting constructive feedback
  • Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
  • Focusing on what is best not just for us as individuals, but for the overall community

Examples of unacceptable behavior include:

  • The use of sexualized language or imagery, and sexual attention or advances
  • Trolling, insulting or derogatory comments, and personal or political attacks
  • Public or private harassment
  • Publishing others' private information, such as a physical or email address, without their explicit permission
  • Other conduct which could reasonably be considered inappropriate in a professional setting

Our Responsibilities

Project maintainers are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.

Scope

This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at . All complaints will be reviewed and investigated promptly and fairly.

All community leaders are obligated to respect the privacy and security of the reporter of any incident.

Enforcement Guidelines

Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:

1. Correction

Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.

Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.

2. Warning

Community Impact: A violation through a single incident or series of actions.

Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.

3. Temporary Ban

Community Impact: A serious violation of community standards, including sustained inappropriate behavior.

Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.

4. Permanent Ban

Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.

Consequence: A permanent ban from any sort of public interaction within the community.

Attribution

This Code of Conduct is adapted from the Contributor Covenant, version 1.4 and 2.0, and was generated by contributing-gen.

Thanks to the following people who have contributed to this project:

Eddie Billoir : eddie.billoir@gmail.com

Ahmad Samer Wazan : ahmad-samer.wazan@irit.fr

Rémi Venant : remi.venant@gmail.com

Guillaume Daumas : guillaume.daumas@univ-tlse3.fr

Anderson Hemlee : anderson.hemlee@protonmail.com

Romain Laborde : romain.laborde@irit.fr

References

[abedinDetectionResolutionAnomalies2006] - [[Abedin, Muhammad, ], [Nessa, Syeda, ], [Khan, Latifur, ], [Thuraisingham, Bhavani, ], ] - Detection and Resolution of Anomalies in Firewall Policy Rules. - 2006.

Summary/Abstract

A firewall is a system acting as an interface of a network to one or more external networks. It implements the security policy of the network by deciding which packets to let through based on rules defined by the network administrator. Any error in defining the rules may compromise the system security by letting unwanted traffic pass or blocking desired traffic. Manual definition of rules often results in a set that contains conflicting, redundant or overshadowed rules, resulting in anomalies in the policy. Manually detecting and resolving these anomalies is a critical but tedious and error prone task. Existing research on this problem have been focused on the analysis and detection of the anomalies in firewall policy. Previous works define the possible relations between rules and also define anomalies in terms of the relations and present algorithms to detect the anomalies by analyzing the rules. In this paper, we discuss some necessary modifications to the existing definitions of the relations. We present a new algorithm that will simultaneously detect and resolve any anomaly present in the policy rules by necessary reorder and split operations to generate a new anomaly free rule set. We also present proof of correctness of the algorithm. Then we present an algorithm to merge rules where possible in order to reduce the number of rules and hence increase efficiency of the firewall.

[sharafExtendedBerkeleyPacket2022] - [[Sharaf, Husain, ], [Ahmad, Imtiaz, ], [Dimitriou, Tassos, ], ] - Extended Berkeley Packet Filter: An Application Perspective. - 2022.

Summary/Abstract

N/A

[jinRABACRoleCentricAttributeBased2012] - [[Jin, Xin, ], [Sandhu, Ravi, ], [Krishnan, Ram, ], ] - {RABAC}: Role-Centric Attribute-Based Access Control. - 2012.

Summary/Abstract

N/A

[balamuruganHoneyBeeBehaviour2015] - [[Balamurugan, B, ], [Shivitha, N Gnana, ], [Monisha, V, ], [Saranya, V, ], ] - A Honey Bee behaviour inspired novel Attribute-based access control using enhanced Bell-Lapadula model in cloud computing. - 2015.

Summary/Abstract

N/A

[kashmarAccessControlModels2020] - [[Kashmar, Nadine, ], [Adda, Mehdi, ], [Atieh, Mirna, ], ] - From Access Control Models to Access Control Metamodels: A Survey. - 2020.

Summary/Abstract

N/A

[ferraioloProposedNISTStandard2001] - [[Ferraiolo, David F., ], [Sandhu, Ravi, ], [Gavrila, Serban, ], [Kuhn, D. Richard, ], [Chandramouli, Ramaswamy, ], ] - Proposed {NIST} standard for role-based access control. - 2001.

Summary/Abstract

In this article we propose a standard for role-based access control ({RBAC}). Although {RBAC} models have received broad support as a generalized approach to access control, and are well recognized for their many advantages in performing large-scale authorization management, no single authoritative definition of {RBAC} exists today. This lack of a widely accepted model results in uncertainty and confusion about {RBAC}'s utility and meaning. The standard proposed here seeks to resolve this situation by unifying ideas from a base of frequently referenced {RBAC} models, commercial products, and research prototypes. It is intended to serve as a foundation for product development, evaluation, and procurement specification. Although {RBAC} continues to evolve as users, researchers, and vendors gain experience with its application, we feel the features and components proposed in this standard represent a fundamental and stable set of mechanisms that may be enhanced by developers in further meeting the needs of their customers. As such, this document does not attempt to standardize {RBAC} features beyond those that have achieved acceptance in the commercial marketplace and research community, but instead focuses on defining a fundamental and stable set of {RBAC} components. This standard is organized into the {RBAC} Reference Model and the {RBAC} System and Administrative Functional Specification. The reference model defines the scope of features that comprise the standard and provides a consistent vocabulary in support of the specification. The {RBAC} System and Administrative Functional Specification defines functional requirements for administrative operations and queries for the creation, maintenance, and review of {RBAC} sets and relations, as well as for specifying system level functionality in support of session attribute management and an access control decision process.

[billoirImplementingPrincipleLeast2023] - [[Billoir, Eddie, ], [Laborde, Romain, ], [Wazan, Ahmad Samer, ], [Rütschlé, Yves, ], [Benzekri, Abdelmalek, ], ] - Implementing the {Principle} of {Least} {Privilege} {Using} {Linux} {Capabilities}: {Challenges} and {Perspectives}. - 2023.

Summary/Abstract

Historically and by default, Linux does not respect the principle of least privilege because it grants all the privileges to administrators to execute their tasks. With the new personal data protection or export control regulations, the principle of least privilege is mandatory and must be applied even for system administrators. The Linux operating system since version 2.2 divides the privileges associated with the superuser into distinct units called capabilities. Linux capabilities allow coarse-grained access control to restricted system features. The “RootAsRole” project is introduced as a solution for delegating administrative tasks while matching the necessary capabilities. However, limitations in user experience and the mapping of Linux capabilities pose significant obstacles. This paper proposes enhancements to achieving a balance between usability and the principle of least privilege, emphasizing the need for precise capability definitions. Future work involves enhancing the RootAsRole access control model and addressing the need for a comprehensive administration access control framework for managing Linux capabilities effectively.

[billoirImplementingPrincipleLeast2024] - [[Billoir, Eddie, ], [Laborde, Romain, ], [Wazan, Ahmad Samer, ], [Rütschlé, Yves, ], [Benzekri, Abdelmalek, ], ] - Implementing the principle of least administrative privilege on operating systems: challenges and perspectives. - 2024.

Summary/Abstract

With the new personal data protection or export control regulations, the principle of least privilege is mandatory and must be applied even for system administrators. This article explores the different approaches implemented by the main operating systems (namely Linux, Windows, FreeBSD, and Solaris) to control the privileges of system administrators in order to enforce the principle of least privilege. We define a set of requirements to manage these privileges properly, striving to balance adherence to the principle of least privilege and usability. We also present a deep analysis of each administrative privilege system based on these requirements and exhibit their benefits and limitations. This evaluation also covers the efficiency of the currently available solutions to assess the difficulty of performing administrative privileges management tasks. Following the results, the article presents the RootAsRole project, which aims to simplify Linux privilege management. We describe the new features introduced by the project and the difficulties we faced. This concrete experience allows us to highlight research challenges.

[wazanRootAsRoleSecurityModule2022] - [[Wazan, Ahmad Samer, ], [Chadwick, David W., ], [Venant, Remi, ], [Billoir, Eddie, ], [Laborde, Romain, ], [Ahmad, Liza, ], [Kaiiali, Mustafa, ], ] - {RootAsRole}: a security module to manage the administrative privileges for {Linux}. - 2022.

Summary/Abstract

Today, Linux users use sudo/su commands to attribute Linux's administrative privileges to their programs. These commands always give the whole list of administrative privileges to Linux programs, unless there are pre-installed default policies defined by Linux Security Modules(LSM). LSM modules require users to inject the needed privileges into the memory of the process and to declare the needed privileges in an LSM policy. This approach can work for users who have good knowledge of the syntax of LSM modules’ policies. Adding or editing an existing policy is a very time-consuming process because LSM modules require adding a complete list of traditional permissions as well as administrative privileges. We propose a new Linux module called RootAsRole that is dedicated to the management of administrative privileges. RootAsRole is not proposed to replace LSM modules but to be used as a complementary module to manage Linux administrative privileges. RootAsRole allows Linux administrators to define a set of roles that contain the administrative privileges and restrict their usage to a set of users/groups and programs. Finally, we conduct an empirical performance study to compare RootAsRole tools with sudo/su commands to show that the overhead added by our module remains acceptable.

[wazanRootAsRoleSecureAlternative2021] - [[Wazan, Ahmad Samer, ], [Chadwick, David W., ], [Venant, Remi, ], [Laborde, Romain, ], [Benzekri, Abdelmalek, ], ] - {RootAsRole}: {Towards} a {Secure} {Alternative} to sudo/su {Commands} for {Home} {Users} and {SME} {Administrators}. - 2021.

Summary/Abstract

The typical way to run an administrative task on Linux is to execute it in the context of a super user. This breaks the principle of least privilege on access control. Other solutions, such as SELinux and AppArmor, are available but complex to use. In this paper, a new Linux module, named RootAsRole, is proposed to allow users to fine-grained control the privileges they grant to Linux commands as capabilities. It adopts a role-based access control (RBAC) [14], in which administrators can define a set of roles and the capabilities that are assigned to them. Administrators can then define the rules controlling what roles users or groups can assign to themselves. Each time a Linux user wants to execute a program that necessitates one or more capabilities, (s)he should assign the role to him/herself that contains the needed capabilities, providing there is a rule that allows it. A pilot implementation on Linux systems is illustrated in detail.