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

What changes when doas configuration is monitored as a security control?

doas is small, but the security consequence is large: a single rule change can expand who may elevate, what command they may run, and whether elevation is passwordless or constrained. Treat the configuration as a high-value control surface. Linux Detection and Response Guide is useful context for the log sources and host telemetry that make this visible.

Configuration monitoring should focus on the files that define elevation policy, plus the surrounding filesystem state that makes those files trustworthy. Unauthorised edits, owner or mode changes, and rule additions that broaden privilege are the clearest signals. In practice, the question is not just whether the file changed, but whether the change altered the effective blast radius of sudo-like access.

A sound baseline includes knowing which users, hosts and automation paths are supposed to use doas, then comparing each observed change against that baseline. If a rule appears suddenly for a new user, a previously restricted command, or a host that does not normally administer Linux systems, treat it as a policy drift event rather than a routine administrative edit.

How do you spot doas abuse in process and authentication activity?

Abuse usually shows up as elevation behaviour that does not match normal operator patterns. Look for unexpected root shells, repeated privilege escalation attempts, commands launched from unusual users or service accounts, and elevation from hosts that do not normally perform admin work. The value comes from correlation, not any single alert.

Authentication and process context matter because doas abuse often looks legitimate at first glance. A successful elevation that follows a benign login is still suspicious if the command, parent process, working directory or source host is inconsistent with the account's normal behaviour. Correlating command execution with interactive logins, tty activity and host identity helps separate approved administration from misuse.

File integrity and activity monitoring should reinforce one another. If configuration integrity fails at the same time that privilege escalation activity rises, the combined picture is stronger than either signal alone. That pairing is especially important when an attacker uses a brief configuration change to create a durable privilege path and then reverts the visible file state.

Which telemetry gives the best signal for doas change detection and response?

The most useful telemetry is the combination of file integrity monitoring, audit-style command logging, and process lineage. File monitoring tells you that the policy changed; process telemetry tells you how the new policy was used; authentication telemetry tells you who was present when the change or abuse occurred. Together, they answer whether the event was maintenance, misuse, or compromise.

On Linux hosts, make sure the logs preserve both the action and the actor. You want the editing process, the account that performed the edit, the command that was elevated, and the time relationship between configuration change and privilege use. Without that chain, you may detect a changed file but miss whether it was immediately weaponised.

When you investigate, compare the current doas configuration against a known-good version rather than reviewing the live file in isolation. That comparison should include file ownership, permissions, rule ordering and any exceptions that weaken least privilege. The practical goal is to explain whether the current state still reflects intended administration or whether it now permits broader access than policy allows.

Practitioner Guidance

What to verify: Confirm that your monitoring watches the exact doas policy files and not just generic Linux paths, and that alerts preserve who changed the file, when it changed and what privilege effect the change created. If you cannot answer those three questions from the alert, the control is too weak to trust.

Decision rule: If a doas change expands privilege or removes a constraint, treat it as a security event first and an administration change second. If the same account also shows unusual root shells or commands, prioritise containment and review before assuming the change was authorised.

Common mistake: Teams often watch only for file modification and miss the more important signal, a new rule that quietly broadens elevation. Another common error is to review doas alerts without correlating them to process execution, which makes abuse look like routine configuration work.

Practitioner takeaway: The strongest detection comes from correlating policy drift with real elevation behaviour, because a harmless-looking edit becomes significant only when it changes who can gain root and what they can run.

Related resources from NHI Mgmt Group

• How can you detect auditd and logging configuration changes on Linux?
• How do you detect changes to federation configuration in Microsoft Entra ID?
• How do you detect application URI configuration changes in Microsoft Entra ID?
• How do you detect setuid and setgid abuse on Linux?