September 30, 2026 · IT-Sicherheit · Zero Trust · Compliance · Schwachstellenmanagement

Least Privilege Is on the Label, Not on the Host

Accounts are deemed minimally privileged, yet the host often allows far more. How to check real permissions and why it takes a negative probe.

“Least privilege” – the principle of minimal permissions – is one of the few security principles nobody objects to. Accordingly, it is written down often: in permission concepts, role descriptions, requests and operations manuals. Yet none of these documents decides what an account is actually allowed to do. That is decided by the configuration of the system on which the account works. This article describes why the two can drift apart, how to establish the actual state, and what needs to be considered before a correction.

What the standards require

In substance, the requirement itself is framed the same way in the common frameworks. NIST describes it in SP 800-53 as control AC-6: only the accesses necessary for the assigned tasks are allowed – explicitly also for processes acting on behalf of users. Automation and service accounts are therefore not exempt, but included. The control enhancements become more specific: privileged accounts are to be restricted to defined persons or roles (AC-6(5)), assigned privileges are to be reviewed regularly for their necessity and revoked where appropriate (AC-6(7)), and the execution of privileged functions is to be logged (AC-6(9)).

In the IT-Grundschutz module ORP.4, the BSI requires the same principle: IDs and permissions may only be granted on the basis of actual need (ORP.4.A2). Requirement ORP.4.A3 is noteworthy. It requires not only that IDs and permission profiles be documented, but that this documentation “must be regularly checked as to whether it reflects the actual state of permission assignment”.

This sets the direction of the check: from the system to the documentation, not the other way round. Documentation that nobody compares with reality describes an intention.

The pattern: the documentation says X, the effective permissions say Y

The deviation is rarely the result of negligence. It arises because permissions take effect in several places at once – and because a name or a description is easier to read than an effective permission. Two textbook examples make this tangible.

Suppose a service account for backups is described in the permission concept as “read-only”. In the directory service, it is a member of a group that is itself a member of an administrative group. Each individual membership looks plausible. Taken together, the account may do far more than read – and anyone who looks only at the direct group membership does not see it.

Suppose a role in a platform bears the name “Viewer”, but in addition to read permissions also contains the permission to change role assignments. The name was chosen correctly; the role was not. Anyone who assigns the role and relies on the name in effect grants the ability to give oneself further permissions.

The same principle applies in both cases: a restriction is enforced only where the target system checks it. What is written in the concept, in the name or in a calling tool is a description, not a control.

Ask the system, not the documentation

As a rule, the actual permissions can be queried directly from the system:

  • On Linux with sudo: according to the manual, sudo -n -l lists the permissions of the calling user on the current host. The -n option prevents any password prompt – if input is required, sudo aborts with an error message instead of waiting. That makes the call suitable for automated checks. With a command appended, sudo answers specifically whether exactly that call would be allowed, without executing it.
  • In directory services: the effective permissions of an account on an object, including nested groups and inherited rights – not the list of groups it is supposed to be a member of.
  • In cloud and platform services: the evaluated policy for a specific action, not the role name.

Without a negative probe, the check proves nothing

A check that only confirms the permitted case has a built-in weakness. The question “may the account do what it may do?” is also answered with yes by an account with full access. The result therefore does not distinguish between a cleanly restricted account and an unrestricted one.

Only the counter-check is meaningful: a request that must be refused. Suppose an account is to be allowed only to restart one particular service. Then the check includes questions such as: may it edit the permission configuration? Create accounts? Start an arbitrary shell with elevated privileges? With sudo -n -l <befehl>, such questions can be asked without executing anything; in directory services and platforms, the evaluations of effective permissions do the same. A no to sudo -n -l /bin/sh does not, however, rule out a root shell: permitted programs with a shell escape – such as find, vim or less – or wildcards in the permitted arguments open the same path. If any of these questions returns a yes, the description is wrong – regardless of what the positive check showed.

Two details make the negative probe reliable. First: evaluate the response, not just the absence of a yes. Otherwise a call that never happened because of a network error or an unexpected password prompt looks like a refusal. Second: the negative probe belongs in the regular review under AC-6(7) and ORP.4.A3, not only in acceptance testing. Permissions change through configuration management, updates and emergency interventions.

Secure the repair path before restricting

Anyone who finds an overly broad permission wants to close it. One principle applies here that is easily missing from plans: a restriction must not remove the only path to its own correction. If the restricted account is also the only one allowed to change the permission configuration, an error in the new rule can afterwards only be fixed via console access, a restore or a rebuild.

The consequence is an order of steps, not a loosening. Before a permission is revoked, it must be clarified which path could grant it back and whether that path survives the restriction. A second, independent administrative identity with its own access should exist and have been tested before the first one is restricted. In ORP.4.A20, the BSI formulates a related idea for emergency preparedness: making provisions to remain operational when permission management itself is not available.

Far-reaching automation accounts are Tier 0

Accounts used for rollout, configuration or automation are often regarded as an operational tool. As soon as they hold far-reaching administrative rights on many systems, they are more than that: whoever controls them controls the systems.

In its enterprise access model, Microsoft describes how the former Tier 0 level was expanded into the “control plane”, and requires the hierarchy to be enforced so that lower levels cannot control higher ones. This explicitly includes continuously looking for configuration weaknesses that enable unintended privilege escalation. For IDs with far-reaching permissions, the BSI recommends multi-factor authentication (ORP.4.A10).

What you should check

  • Establish effective permissions – for every service and automation account, on the system.
  • Define a negative probe for every positive check that must be refused.
  • Anchor restrictions where they are enforced.
  • Establish and test the repair path before every restriction.
  • Treat far-reaching automation accounts like Tier 0: multi-factor protection, logging, named responsibility.

How sector7 supports you

We support you with role and permission concepts, the management of privileged accounts, multi-factor authentication and the hardening of operating systems – including policies, documentation and audits. More under cyber security.

Sources

Let's talk about your situation.

Arrange a call+49 212 240915 0