doas

What doas is for

doas is a Unix-like privilege elevation tool that lets a user run a single command as another user, often root, under tightly defined policy rules. It is intentionally smaller and simpler than some alternatives, so its security value comes from reducing the amount of policy surface, keeping privilege decisions explicit, and limiting how much power is granted by default.

That narrow design makes doas a control point for administrative access rather than a general-purpose shell wrapper. In practice, the important question is not just whether a user can elevate, but which commands they can run, whether the invocation is logged, and whether the policy file reflects the minimum necessary privilege.

How doas policy works

doas typically relies on a small configuration file that defines who may elevate, to which target user, and for which commands. That means policy is usually easier to audit than sprawling privilege models, but it also means a mistake in a short ruleset can be highly consequential. A broad rule can quietly turn a convenience tool into near-root access.

The core security idea is command-scoped delegation. Instead of handing out interactive administrative access, doas can be used to permit a specific maintenance task, script, or troubleshooting action. That makes the policy model closer to least privilege than blanket administrator membership, provided the rules stay narrow and current.

Operational and security implications

Because doas can execute commands with elevated authority, it sits directly on the boundary between ordinary user activity and system control. If a permitted command is itself too powerful, indirectly configurable, or capable of spawning a shell, the privilege boundary may be weaker than the policy appears. On shared systems, that distinction matters more than the choice of tool name.

doas also changes the operational profile of administrative access. It can reduce dependence on long-lived interactive root sessions, but it does not remove the need to manage who can elevate, which commands are approved, and whether the resulting activity is visible to operators and auditors. In other words, the security value comes from policy discipline, not from the utility alone.

When to use doas instead of broader privilege tools

doas is most useful when an organisation wants a compact, reviewable elevation policy for a limited set of administrators or automation tasks. It fits environments that value simplicity and explicit command allowance over feature-heavy privilege workflows, especially where fewer moving parts is itself a security objective.

It is less suitable when the organisation needs highly granular delegation, extensive session controls, central policy orchestration, or a larger governance layer around privileged access. In those cases, the operational requirement may exceed what a minimal elevation tool is meant to solve. The right choice depends on whether the use case is simple command delegation or full privileged access management.

Risk and Threat Considerations

Privilege elevation tools are attractive to attackers because any rule that grants the wrong command, target account, or execution context can become a fast path to higher access. The main risks are overbroad delegation, command abuse, and escalation through a permitted binary that can be repurposed for more than the policy author intended.

Failure mechanism: A policy rule that looks narrow may still allow privilege escalation if the approved command can invoke a shell, edit sensitive files, run arbitrary subcommands, or otherwise break out of the intended restriction.

Impact: A compromised standard user account can be turned into administrative access, which can expose system configurations, secrets, logs, and service controls and can accelerate lateral movement on the host.

Practitioner Guidance

Why practitioners should care: doas is only as safe as the policy file behind it. Review the rules as security policy, not just as convenience configuration, and treat every permitted command as an authority grant that needs a clear business justification.

What to watch for: pay close attention to rules that permit broad command families, interactive shells, wildcard-like patterns, or commands that can read and modify privileged files. Those are the places where a simple elevation model can quietly become too permissive.

Practitioner takeaway: keep doas rules narrow, auditable, and periodically revalidated so the tool remains a controlled delegation mechanism rather than a standing shortcut to root.

Related resources from NHI Mgmt Group

• How do you detect doas configuration changes and abuse on Linux?