v3.1.0

[LeChatP]

Performance, configurability, features update

New Features

add -E (--preserve-env) for preserving environment variables from current execution environment.

{{If a task allow to override-env option, the users could replace the environment variable from Delete decision to Keep. This still applies env check, del and set policies, so still filters env variables
Let's take an example :

{
  "name":"permissive-task",
  "options": {
    "env": {
      "default": "delete",
      "add": ["HOME"],
      "check": ["TZ"],
      "del":["PERLLIB"],
      "set": { "PS1" : "RaR task $"}
    },
    "override-env": true
  }
}

When the user will use sr <command> the command will:

• delete all variables by default except for next rules:
• keep HOME value
• check TZ value and keeping if valid
• set PS1 set as "RaR task $" value.

And when the user will use sr --preserve-env <command>, the command will :

• keep All current env variables by default
• check TZ value and keeping if valid
• set PS1 set as "RaR task $" value.
• delete PERLLIB variable

Note: Enabling this option lowers the task's priority in the automatic selection (when no argument are written). Therefore, if an identical task exists without this option, it will be selected first.

add -u option (Thanks to Hocine)

Now setuid element is not just a string, it could be a structure, defining a set of users to change to, an enhanced and various ways than sudo. Let's take few examples:

{
  "name":"permissive-task",
  "cred": {
    "setuid": ["user1","user2"]
  }
}

This allows users to do sr <command>, it will automatically take the first user for setuid by default. The user could also do : sr -u user2 <command> and it will execute the command with the user2 in setuid.

{
  "name":"permissive-task",
  "cred": {
    "setuid": {
      "fallback": "user1",
      "default": "all",
      "del": ["user2"]
    }
  }
}

This example sets user1 as a "fallback" setuid user if no -u specified. Now users could become any user using -u except user2

Add -g option (Thanks to Hocine)

As the same manner than -u does, -g allows to users to specify a set of groups. The subtle is that it manages a set of groups making it a bit complexier than setgid as you can define array of groups, and the matching is always strict.

Note (already present in previous versions): setgid() is always the first group in a list, then the rest of groups are setgroups()

Implementing Interchangeable file format with CBOR and JSON

Since we've shifted our RootAsRole configuration from XML to a JSON base in 2023 or 2024 (I don't remember well), we decided to change the design of our tool to make it policy language-agnostic while still setting JSON for policy format and location. So today we implemented CBOR file format for performance objective.

Funnily enough, we initially considered supporting XML because it offers features JSON doesn't natively, like directly translating files to ASN.1 for an optimized binary format. But hey, we've basically rebuilt that functionality in a modern, dev-friendly way thanks to serde library.

🚀 Optimizing sr: A Performance Leap Over sudo and sudo-rs

Thanks to ESORICS conference reviewers, we took an special care to optimizing our tool. Indeed, reviewers were wondering that our new gensr automation tool were introducing a lot of rules for an Ansible playbook, and we didn't evaluate the performance in consequence. We indeed found performance issues initially. But we heavily optimized the whole tool. We compared to sudo and the graph is clear: 77% better raw performance, 45% better slope than sudo implementation.

You could reproduce it in this repo.

I recently tried to put sudo-rs through its paces to evaluate its performance, but I hit a wall. Unfortunately, it seems like scalability might not be a priority for them, and an issue I created (here) is set to "won't fix" for now. From the little I was able to test, the performance is either the same as, or even worse than, regular sudo. It really feels like sudo-rs is more or less a direct copy of the C sudo code in Rust.

Tests, tests, tests

We wrote a bunch of tests. It highlighted some bugs in the code which were instantly solved after tests writing. We think that we tested most of use-cases. Since 2024, we reviewed several times the tests.

About deploying RootAsRole to distributions

As for the package deployment, I really need your help to bring the project to Linux distributions repositories!

I've started working on it myself, starting with creating Debian packages for dependencies. There are many missing packages in the dependency tree, so it's not a simple task. To top it off, some of these dependencies appear to be unmaintained. I even had to take over the maintenance of rust-pam-client crate (so republishing to a pam-client2...), because the main contributor didn't respond to my emails or GitLab messages.

The main objective is to publish a first package called sr which deploys sr and chsr binaries. I still hesitate if I separate sr and chsr onto two distinct packages, but I think chsr is useful. Then in a second step generating a package like gensr or/and capable packages for having RootAsRole configuration helpers.

If you have experience packaging for different Linux distributions, your help would be greatly appreciated.

---

This discussion was created from the release v3.1.0.