Ultimate Guide to sudo Permissions and Command Logs (AC.L2-3.1.7)

To meet AC.L2-3.1.7, an organization must define privileged and non-privileged users, prevent standard users from performing administrative functions, and record every privileged command execution in auditable logs. Effective sudo permissions privileged command audit logs combine least-privilege authorization, controlled elevation, centralized log collection, and regular review so the organization can show who ran an administrative action, on which system, and when.

For a program manager, the practical outcome is evidence that access is deliberately designed rather than inherited: approved administrators can perform only assigned tasks, ordinary users cannot elevate at will, and security staff can trace privileged activity during an incident, customer inquiry, or CMMC assessment.

What does AC.L2-3.1.7 require an organization to do?

NIST SP 800-171 Rev. 2 practice AC.L2-3.1.7, used in CMMC 2.0 Level 2 assessments, requires organizations to prevent non-privileged users from executing privileged functions and to capture the execution of privileged functions in audit logs. It works alongside AC.L2-3.1.2, which limits users to authorized functions, and AU.L2-3.3.2, which requires logging and traceability of user actions.

The control is not satisfied merely because a Linux server has sudo installed or because a firewall has an administrator password. Assessors will expect the organization to show that privileged access is intentionally assigned, technically enforced, logged, protected from alteration, and reviewed.

Which functions and users should be treated as privileged?

Privileged functions are actions that control, configure, monitor, secure, or materially alter a system. On Linux, examples include installing software, changing firewall rules, creating accounts, editing authentication settings, restarting production services, accessing security logs, modifying backups, and changing sudo policy. In cloud and network platforms, privileged functions include changing identity roles, security groups, virtual private network configurations, logging settings, and administrator accounts.

A privileged user is not necessarily a permanent “admin account.” A help-desk technician approved to reset passwords may have a narrow privileged function. A systems engineer may be allowed to apply approved patches but not create accounts or disable endpoint protection. A non-privileged user should have only the rights needed for ordinary duties, such as using approved business applications, viewing assigned project files, or submitting service requests.

Document these categories in a role matrix. Avoid informal labels such as “power user” without identifying the exact elevated capabilities that label grants. The matrix should map each role to approved systems, commands or functions, approver, business justification, and review frequency.

How do sudo permissions privileged command audit logs work together?

On Linux, sudo is often the primary enforcement point: it allows a named user or group to run a specific approved command as root or another authorized account. The safest model is not broad ALL=(ALL) ALL access for operational staff. Instead, authorize narrow commands, require authentication where appropriate, prevent interactive root shells, and log the command, invoking user, target host, target account, and result.

Command logging should not rely on one local text file. Local logs can fill, be deleted by a privileged user, or be unavailable after a compromised host is rebuilt. Forward sudo and operating-system audit events to a centralized log platform with access controls and retention appropriate to contractual, legal, and investigative requirements. Configure alerts for high-risk actions, failed elevation attempts, changes to sudo policy, and use of break-glass accounts.

For stronger accountability, enable sudo input/output logging for sensitive administrative systems. Session recording can answer questions that a command line alone cannot, such as what configuration changes were made after an administrator opened an approved utility. Apply this carefully: recordings can capture sensitive data, so restrict access and define retention.

What should a practical implementation path look like?

1. Identify in-scope systems and CUI workflows. List Linux servers, network devices, cloud tenants, security tools, backup platforms, and administrative jump hosts used to support covered work. Record where privileged actions occur and where their logs are collected.
2. Create a privileged-function inventory. Define functions such as patching, identity administration, backup recovery, endpoint-security administration, firewall management, and log-management administration. Assign each function to a business role and an approving manager.
3. Separate standard and administrative identities. Administrators should use standard accounts for email, collaboration, and ordinary work, then elevate only when needed. Where feasible, prohibit direct root login and require administration through named accounts.
4. Build least-privilege sudo rules. Use groups tied to roles, not one-off unmanaged exceptions. Prefer root-owned scripts with fixed behavior for complex tasks instead of granting unrestricted interpreters, editors, package managers, or shells that can be used to bypass a command restriction.
5. Enable command and policy-change logging. Configure sudo logs and operating-system audit rules, then forward them to the SIEM. Validate that the receiving platform retains usernames, hosts, timestamps, command details, success or failure, and source integrity information.
6. Test both allowed and denied paths. Have an authorized administrator execute an approved command and have a non-privileged test account attempt the same command. Verify the standard user is blocked and that both the permitted execution and denied attempt are visible to the reviewer.
7. Review and maintain evidence. Review privileged group membership and sudo rules at least quarterly and after role changes. Review privileged activity on a defined cadence, investigate anomalies, and retain review records.

For example, Meridian Technical Services, a 70-person MSP supporting several regulated customers, uses Ubuntu jump hosts for its 14-person infrastructure team. Patch technicians belong to patchops and can run only a root-owned approved patch script during scheduled windows. Senior platform engineers belong to a separate group with additional recovery permissions. Neither group receives unrestricted root shells, and customer-specific administration is performed through named accounts rather than shared credentials.

# /etc/sudoers.d/patchops — edit with visudo
Defaults use_pty
Defaults logfile="/var/log/sudo.log"
Defaults log_input, log_output
Defaults iolog_dir="/var/log/sudo-io/%{user}"

Cmnd_Alias APPROVED_PATCHING = /usr/local/sbin/approved-patch-run
%patchops ALL=(root) APPROVED_PATCHING

# Explicitly avoid granting sudo access to shells or interpreters:
# /bin/bash, /bin/sh, /usr/bin/python3, /usr/bin/vi

The root-owned approved-patch-run script can enforce an approved repository, write a change identifier to its own log, and reject execution outside the maintenance window. This is more defensible than allowing a technician to run any package-manager command as root.

On the same hosts, Meridian sends sudo events through rsyslog and audit events through auditd to its SIEM. The following audit rules help detect sudo execution and changes to the policy that governs it:

-a always,exit -F arch=b64 -S execve -F path=/usr/bin/sudo -F perm=x -k privileged-sudo
-w /etc/sudoers -p wa -k sudoers-change
-w /etc/sudoers.d/ -p wa -k sudoers-change

Before deployment, the system team should validate rules in its operating-system version and ensure audit daemon configuration changes are managed through approved configuration management.

What evidence should a program manager collect for an assessment?

Build an evidence package that connects policy, technical configuration, and operating practice. A policy without logs does not prove enforcement; logs without a role model do not prove least privilege. Ask technical owners to provide samples that are recent, attributable, and drawn from the actual in-scope environment.

• Policy and procedure: A documented access-control and privileged-access procedure defining privileged functions, account types, approvals, logging, reviews, and exception handling.
• Role matrix: A current list of privileged groups and authorized functions, including business owners and access approvers.
• Configuration evidence: Sanitized sudoers files, identity-group configuration, root-login settings, and SIEM forwarding configuration.
• Log evidence: Search results showing a successful privileged command, a failed or denied elevation attempt, a sudoers change, and the same event in centralized logging.
• Review evidence: Quarterly membership reviews, privileged-log review records, tickets for investigated anomalies, and terminated-user access removal records.
• Testing evidence: A documented test showing that a non-privileged account cannot perform a protected action.

What is the AC.L2-3.1.7 compliance checklist?

• □ Privileged functions are identified for every in-scope platform.
• □ Standard users and privileged roles are defined in documented access procedures.
• □ Each privileged role has a business owner and approval path.
• □ Administrators use named accounts rather than shared administrative credentials.
• □ Non-privileged users cannot obtain root, local administrator, or equivalent cloud and network privileges.
• □ Sudo rules grant only required commands or controlled scripts, not broad unrestricted access.
• □ Direct root login and unnecessary standing administrator access are disabled or tightly controlled.
• □ Privileged command execution is captured with user, system, time, command, and result.
• □ Changes to sudo policy and privileged-group membership are logged.
• □ Logs are forwarded to a centralized, access-controlled repository.
• □ Failed elevation attempts and high-risk privileged actions are monitored and investigated.
• □ Privileged access, sudo rules, and logs are reviewed on a documented schedule.

Frequently asked questions about AC.L2-3.1.7

Does AC.L2-3.1.7 require sudo on every system?

No. The practice requires prevention and logging of privileged functions, not a specific tool. Linux systems may use sudo; Windows may use role-based access control, privileged access management, and Windows event logging; network appliances and cloud platforms may use their native administrative roles and audit trails. The organization must show equivalent enforcement and traceability.

Is a local /var/log/sudo.log file enough for CMMC Level 2?

Usually, a local file alone is weak evidence because it can be lost or altered during an incident. Centralized collection, protected access, retention, and review provide a more reliable audit trail and better support AU.L2-3.3.2. The precise architecture should match system risk and documented policy.

Do we have to log failed sudo attempts as well as successful commands?

The explicit requirement focuses on capturing privileged-function execution, but logging denied and failed elevation attempts is a strong implementation practice. It helps identify attempted abuse, misconfigured access, and potential account compromise, and it supports the requirement’s intent to manage attempts by non-privileged users.

Can an administrator have ALL=(ALL) ALL in sudoers?

Some highly trusted infrastructure roles may require broad authority, but unrestricted sudo should be exceptional, justified, approved, and regularly reviewed. It is not appropriate for ordinary users or routine operational roles. Where broad access remains necessary, use named accounts, multifactor authentication where available, centralized logging, session recording for sensitive systems, and compensating monitoring.

How often should privileged access and command logs be reviewed?

Review frequency should be risk-based and documented. Many organizations review privileged group membership quarterly, review high-risk alerts continuously or daily, and conduct a formal privileged-log review monthly. Critical systems, incident periods, and break-glass account use warrant faster review and documented follow-up.

Next step: Assign each in-scope system owner a two-week task to validate privileged roles, test a denied elevation attempt, and provide one centralized log sample for your AC.L2-3.1.7 evidence package.