Skip to content

Conversation

@LeChatP
Copy link
Owner

@LeChatP LeChatP commented Jul 15, 2025

My personal MR:
This merge request introduces version 3.1.0, focusing on performance improvements, enhanced configurability through environment variables and CBOR interchangeable file-format support, updated documentation and adds many tests.

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


Some Copilot Slop :

Configuration Enhancements:

  • .cargo/config.toml: Added environment variables for RootAsRole configuration, including paths, timeout settings, and authentication options. These additions provide more flexibility and control over the tool's behavior.
  • book/src/chsr/file-config.md: Updated configuration examples to include CBOR support, full command paths, and additional environment variable options. This improves clarity and reflects the new capabilities introduced in version 3.1.0. [1] [2] [3] [4]

Documentation Improvements:

  • README.md: Updated to reflect version 3.1.0, added performance comparisons with sudo and sudo-rs, and highlighted new features like CBOR support and enhanced command execution options. [1] [2] [3] [4]
  • book/src/SUMMARY.md and book/src/chsr/convert.md: Added a new section on file format conversion, detailing how to switch between JSON and CBOR formats for configuration files. [1] [2]

Continuous Integration Update:

  • .github/workflows/tests.yml: Enabled privileged mode for the container used in testing workflows to support advanced security configurations.

LeChatP added 30 commits March 28, 2025 20:58
We need to add manually the file in order to update config
This huge commit is rewriting the optimisation, securing everything and simplifying.
LeChatP and others added 29 commits May 4, 2025 14:15
Optimize RootAsRole sr program
refactor: MORE optimization by using constants instead of dyn alloc...
@LeChatP LeChatP merged commit 74778e9 into main Jul 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants