v3.0.0

🎉 RootAsRole v3.0.0 is Here! 🎉

What Does This Mean? 🚀

This release marks a huge milestone for RootAsRole! After months of dogfooding RootAsRole in my own setup without a hitch, I'm excited to finally say: we’re ready for deployment!

In addition to thorough automatic unit testing, I’ve been hard at work reviewing CVEs from both the Sudo-rs and sudo projects, ensuring RootAsRole remains secure and solid. Along the way, I squashed some bugs (all tracked in the commits), further polishing the reliability of the tool.

One major update: we've extracted the "capable" tool into a separate repository—it's a bit of a heavyweight right now and not quite ready for daily production. This way, RootAsRole stays lean and clean, with a lighter development environment for you.

What's New? ✨

• 🛠 Tons of fixes following daily personal use, making RootAsRole smoother than ever!
• 🌟 "capable" has a new home in its own repo: RootAsRole-capable.
• 🤖 Automated deployments with easy-to-use .deb and .rpm packages.
• ⚡️ Simplified installation process and streamlined dependencies.
• 🧑‍💻 Optimized binaries that now require fewer C libraries—just libc for chsr, and pcre2 + pam (and libc) for sr.

And since v2.X, what happened ?

It's been a long journey. In October 2021, I started my PhD on the principle of least privilege, a logical continuation of my previous work during a second-year graduate internship. Two years later, I'm delighted to have deepened my research and significantly improved RootAsRole, in line with the state of the art and usability principles.

When I took over this project, I initially set out to make it ‘usable’ and ‘reliable’, so that it would provide accurate and fancy results for the research articles I was writing. However, as I worked on the new features, I discovered that managing memory security was impacting my productivity, as I had to continually check previously developed elements, in the fear of missing something that could be a big issue.

That's when I discovered Rust, a good solution for my fears! During a holiday, I decided to immerse myself in this language by completely rewriting RootAsRole. What a complex language! But right from the start, I knew that this work would save me a considerable amount of time.

Since version 2.X, it had become clear to me that there was a conceptual problem with RootAsRole. So I scrupulously followed the RBAC standards and their various variants (RBAC-0, OrBAC, etc.), which enabled me to clarify the conceptualisation of the tool. A quick note: in examining a lot of code, I've noticed that many libraries and services claiming to implement RBAC are mistaken.

I quickly implemented RBAC-0, then I implemented the static separation of roles, the hierarchy of roles in ‘plugins’, judging that they were not necessarily necessary in personal environments for example. I also rewrote the configuration file in JSON rather than XML, because no library provided all the functionality needed in XML (DTD, comment management). Conceptually, the policy is sufficiently structured to be stored in a relational database. I therefore decided to split the configuration in two: a ‘fixed’ part containing information about the policy, and the policy itself stored in another file, or directly integrated into the same file in JSON. I've also set up a versioning mechanism and a transparent update of the configuration and the policy.

chsr is a difficult policy modification tool to conceptualise. I looked for complex commands that had very good clarity, and I took inspiration from the ip and nftables commands for the organisation of my command. To do this, I had to learn how to write a grammar for a parser, and I discovered the pest library, which allowed me to do this easily with Rust.

Also, I had this thought: if you give administrator rights to a user, he can change the policy and roles, it is not desirable. So I made the RootAsRole configuration immutable with the chattr +i file system attribute. Also, I've gained a better understanding of everything that's possible with Linux capabilities, but above all everything that's really useful and practical for a privilege management tool.

Speaking of performance, I was able to run an initial benchmark between the version of sudo (C version) installed on my machine and RootAsRole. I was pleasantly surprised to find that RootAsRole was around 60% faster than sudo for the simple ‘sr ls’ and ‘sudo ls’ commands. However, further tests are needed to confirm these results and explain why a such huge difference.

Today, I'm proud to present RootAsRole 3.0, a complete, secure and easy-to-use role management tool. I hope you'll find it useful and enjoy using it as much as I enjoyed developing it. Don't hesitate to send me your feedback, I'm always interested in your suggestions for improving this tool. I'm counting on you to help me to make it even more secure, efficient, useful and reliable.

As capable is now in its own repository, I have many objectives, aligning with my PhD studies, and this is so exciting! So tomorrow, I am focusing on this tool that helps configuring RootAsRole.

In the future, I intend to continue to maintain the project, study proposals and improve RootAsRole.

Full Changelog:

Check out all the details here.

Thank you all !
Eddie

v3.0.0-alpha.5

What's Changed

• Addressing sudo's CVE that are potential to RAR by @LeChatP in #49
• v3.0.0-alpha.5 by @LeChatP in #50
  • Making capable usable (not completely practical for now)

Full Changelog: v3.0.0-alpha.4...v3.0.0-alpha.5

v3.0.0-alpha.4

This new release adds many new features! With its comprehensive documentation and many unit tests.

Merges

• Update README.md by @SamerW in #38
• Patch install process by @LeChatP in #39
• v3.0.0-alpha.4 by @LeChatP in #42
• Bugfixes, Tests & Docs by @LeChatP in #43
• Hashchecker fix + docs by @LeChatP in #44
• Tests and bugfixes by @LeChatP in #45
• Capable: Add json output by @LeChatP in #46
• Fixes and tests + Better conflict resolution + Scenarios in documentation by @LeChatP in #47
• Fix env vars + erasing password in-memory by @LeChatP in #48

Replacing XML to JSON file format

• The project now embraces JSON for configuration management, offering improved flexibility.
• After careful consideration among JSON, YAML, or KDL, JSON emerged as the preferred choice.
  1. chsr is simple enough to avoid direct file manipulation
  2. JSON is the industry's most used and interoperable.
  3. Discouraging text editing because rootasrole.json should be immutable, as using chattr is annoying
  4. Other formats allow commenting but these would be deleted each time using chsr tool.

Adding new configuration file for storage configuration

As RootAsRole implements the RBAC model, it would be interesting to plan the database integration, such as LDAP for user assignment and SQLite/PostgreSQL/MySQL for role and task definitions.

Rewrite of chsr tool

• The chsr tool has undergone a complete rewrite, eliminating the Text User Interface (TUI).
• Concerns regarding usability inefficiency drove the decision to move away from TUI.
• The new Command-Line Interface (CLI) offers enhanced usability and efficiency in managing roles.
  • Inspired by tools like ip or nftables, the new CLI syntax is intuitive and user-friendly.
  • We developed a grammar pest to enable syntax management like these tools, as clap-rs couldn't suffice.
• Closing #41

Plugin-based features

RBAC-0 features are now core program features, with the implementation of hierarchical roles moved to an 'API'. This facilitates the addition of new features for the separation of duties.

Other new features

• The sr command now operates in a pty, mitigating tty hijacking risks.
• password is now erased from memory after use.
• Enhanced options include:
  • Multiple environment variable management policies for flexibility in handling environment variables.
  • Inheritable option management allows administrators to define general and specific options with inheritance control.
  • Timeout is now an option per-task, providing granular control over task execution.
• Fixes #40

Full Changelog: v3.0.0-alpha.3...v3.0.0-alpha.4

3.0.0-alpha.3

By rewriting this program entirely in Rust, I could add new features quickly and get almost the same performance as the C version. Rust language is appropriate for our software. And the rewriting was easy.

However, today, I would like to say what differs in this version:

From the most to the least exciting changes

• Full Rust Rewriting, no more C !
  • The sr binary is to execute a task with a role
  • The chsr binary is to modify the configuration and the RootAsRole policy with command line arguments or fancy terminal interface
  • The capable binary determines which capabilities are needed for a program.
• Role hierarchy managed (role parents' tasks will be included)
  • Parent roles and their tasks are Included in partial order comparison.
  • This role will be chosen if a task is less privileged in its parents.
  • TODO: chsr needs to be managed with cursive.
• Static separation of duties (SSD) implemented
  • If one role defines another role as SSD, actors cannot be in this role
  • This is checked on chsr. Configurator no longer needs to check it manually; it will be informed as denied.
  • This is checked on sr. If a user is added to a group that conflicts with SSD, conflicting roles are forbidden.
  • TODO: Editing the configuration of SSD with chsr.
• sr now handles timestamp cookies!
  • This means that sr doesn't require authentication for every command executed before a certain delay. This is entirely configurable like sudo does.
• Thanks to the Aya framework, The capable eBPF program is now in Rust. It simplifies the compilation process, which was the main problem with the C version.
• Capabilities are now entirely documented, thus automatically dumped from the capabilities manual.
• Better Command parsing
  • Binary Path is matched with the extended glob syntax.
    • ** means any path; you could translate it by "anything, everywhere".
    • * means any direct file on the current path here will be relative to the current working directory.
  • The previous meaning of ** was changed to ALL. So ALL means any command and any arguments. This is because the meaning of ** exists in the glob syntax and could be confusing.
  • Paths are now canonicalized.
  • Arguments can use PCRE2 to match. See here to build your regular expression
• Configuration file Versionning management implemented
  • This means that any upgrade of the current configuration will be managed and automatically migrated from one version to another.
• Now, capabilities can be denied from role definition, and their parents are included
• libxml2 is still needed to verify DTD
  • This negatively impacts performance because the program parses two times the configuration file
  • Today, XML rust crates do not provide every needed feature. SXD is the most complete one, so I implemented a part of libxml2 C bindings, but it needs to be completed and could be complex to enhance.
  • One day, I will consider migrating to JSON or YAML... However, I enforce the need for Schema Validation, which is not provided by default.
• Switched to Termion backend for cursive interface.

Full Changelog: v3.0.0-alpha.2...v3.0.0-alpha.3

3.0.0-alpha.2

What's Changed

• Working Role manager by @LeChatP in #20
• Prepare for v3.0.0-alpha.2 by @LeChatP in #21
• new default conf for rootasrole by @LeChatP in #22
• Change workflows by @LeChatP in #23
• bugfix + more tests by @LeChatP in #25

Full Changelog: v3.0.0-alpha.1...v3.0.0-alpha.2

This version is considered as functional. But we need more tests and are working on a new configuration, for usability.

3.0.0-alpha.1

This new version implementation is entirely different from previous ones. Many design decisions were taken. SamerW passed the project lead to LeChatP for availability reasons. But SamerW and Romain Laborde are still following the project ideas.

What's Changed

• sr implementation to a more secure one
  • We simplified the manipulation of capabilities sets and reduced the attack-vector surface
  • We implemented partial order comparison on the entire configuration, resolving most conflicts between roles.
  • We manage the entire credential manipulation
    • variables environment are allowed, filtered, or removed by default.
    • setUID managed
    • multiple setGID managed
    • capabilities bounded by default
  • The role selection complies with partial order comparison to select the proper role according to user input.
  • We allow fine-grained settings that could be applied to the entire file, role or task configuration.
• capable is functional for multiple distributions: Ubuntu, Debian, Archlinux
• role-manager is under development to an evolutive Rust implementation
• New AI-generated logo
• Implemented Unit Tests for C with Criterion;
• We added quality code and test code coverage indicators.
• We encourage security experts to find security issues, so we added the SECURITY.md security policy.

Full Changelog: V2.3.1...V3.0.0-alpha.1

Next Steps

First, We wanted to add tests to our program and improve code quality. Documentation will be available soon. Since it's only an alpha version, many things are missing from our new perspectives :

• Role hierarchy (tasks inheritance)
• Configuration permissions (limit the scope of configurators)
• SELinux features
• Layered capability bounding (Task, Role, or Entire configuration)
• Capabilities Semi-Autoconfiguration (use capable tool to configure tasks)
• Roles canvas (default configuration adapted to IT jobs, with emergency cases to secure the default usage)
• Make the project binaries available on package manager repos
• Import sudo configuration into our tool

With these changes, RootAsRole is meant to be a production-ready project.

2.3.1

Merge pull request #15 from SamerW/manager-branch

Manager branch

2.3 - Add Edit Delete roles and fixes

This release allow to add, edit or delete roles interactively through commands
Also, ebpf is fixed for ubuntu jammy

1.1 - Remove role argument for some cases and make automated tests

The goal of this release is to simplify the utilisation of sr command by removing role argument when specifying a command with sr.
See Changelog here