Introduction
Cybersecurity threats are not just from outside. The major landscape of cybersecurity is undergoing a shift, with threats originating from within organizations’ trusted boundaries now posing a risk as significant as external attacks.
Yearly Data Breach Investigations Reports by Verizon state that “between 20 and 35% of breaches were caused by insiders” (e.g., employees, contractors, and other trusted individuals). Financial motives are frequently the root cause of these incidents, revealing that individuals granted excessive trust and access within an organization can abuse their privileges for personal reasons. This clearly emphasizes the significant role of internal threats in modern cyberattacks and the need to monitor and control privileged access to a system properly. Managing user privileges is particularly challenging due to modern networks and software components’ growing complexity and technological heterogeneity.
Some incidents illustrate the scale of these threats. For example, a former Ubiquiti cybersecurity engineer exploited administrative access to steal confidential data, extort money from the company, and significantly damage its reputation. Similarly, a former Chief Information Security Officer (CISO) of the Hospi Grand Ouest healthcare group in France orchestrated a cyberattack that compromised sensitive healthcare data. In March 2025, a former employee in Ohio was found guilty of installing a kill switch—a mechanism designed to destroy the infrastructure—in the event his privileged account was revoked. These cases, frequent in the news, underscore the urgent need for a targeted approach to securing administrative privileges, particularly in environments where the risk of abuse is high.
Company employees can have malicious intentions, but they can also, unbeknownst to them, become involuntary attackers. Current IT ecosystems are software supply chains, where an application depends on a long chain of other software modules developed and maintained by third parties. For instance, in the context of development environments, vulnerabilities in third-party code, such as VSCode extensions, can become attack vectors, undermining entire systems.
This internal threat is further amplified by the interconnected nature of modern software, which functions as a vast supply chain. A vulnerability concealed within a third-party library or a development tool can be exploited to compromise an entire infrastructure, turning even the most diligent administrator into an unwitting accomplice. The recent XZ incident or an innocent Visual Studio Code module is a potent reminder of this reality. Consequently, the focal point of risk converges on the concept of privileged access. The superuser accounts used by system administrators, by their very nature, offer almost unlimited control and thus represent the most fertile ground for exploitation, whether through malicious intent or unintentional error.
Faced with this challenge, cybersecurity has provided since the 1970s a clear theoretical answer: the Principle of Least Privilege (PoLP). Formulated by Saltzer and Schroeder, this principle is an engineering process that involves understanding users’ responsibilities to grant them only the minimum permissions required to accomplish their tasks using computer systems. This project focuses on a critical application of this doctrine, the Principle of Least Administrative Privilege (PoLAP), which concerns those administrators who manage and modify the system itself. In principle, the systematic application of PoLAP is already encompassed by PoLP. However, the position of Administrator is generally already an exception in the infrastructure design. Whereas it should be an exception, the reality shows in big companies that hundreds of administrators become Administrator of every new system installed, duplicating the risk considerably.
A significant gap persists between this principle and its practical implementation. On modern operating systems, particularly Linux, enforcing PoLAP is a task of considerable complexity. The administrator is confronted with a mosaic of disparate and overlapping security mechanisms: POSIX permissions, ACLs, Linux Capabilities, SELinux, AppArmor, and others. The attempt to configure these mechanisms coherently creates a daunting administrative burden. The typical response of adding a new security module often serves only to augment this complexity, failing to address the fundamental challenge of orchestrating all of these security mechanisms in a coherent policy.
The central premise is that the root cause of this failure is not technical, but lies in an incomplete methodology and a lack of consistency in the security mechanisms implemented. We postulate that a solution cannot be found by adding another layer of technology, but rather by adopting a new perspective—one that uses security models that acknowledge user needs for security. A security mechanism that is too complex, or doesn’t include user needs is, in effect, insecure. It is by examining the origins of our concepts of hierarchy, order, and control, and by placing usability at the center of the design, that we can hope to develop truly effective solutions.
It is from this perspective that we developed the RootAsRole (RaR) project. RaR is not presented as yet another security module to be added to the existing stack. Rather, it is conceived as a security orchestrator, in addition to being a better alternative to solutions found in the open-source community. As a performant, memory-safe, user-centric alternative to traditional tools like sudo, its purpose is to bring order and clarity to the existing complexity. It simplifies the management of fine-grained permissions and enables a pragmatic application of PoLAP through the Just-in-Time (JIT) elevation of privileges. RaR is thus the materialization of our approach: a pragmatic solution designed to make secure co-administration an achievable reality.[Billoir 2025]