Access Control: Accounts, Sudo and Logins

What Access Control Means

Access control answers one question: may this subject do this action on this object? The subject is a user or a program. The object is a file, a service or a command.

Authentication proves who the subject is. Authorisation decides what that subject may do. A strong password with a NOPASSWD sudo rule behind it is good authentication and no authorisation.

Two habits make access control work. Least privilege gives each account only what its job needs. Default deny refuses anything that is not explicitly allowed.

NIST SP 800-53 groups these controls in the Access Control (AC) and Identification and Authentication (IA) families. CIS Controls v8 covers them in Controls 5 and 6.

Who May Log In

Every account that can log in is a door. Service accounts such as www-data or postgres should have a nologin shell, because nothing should ever log in as them.

An account with an empty password field is a door with no lock. OpenVAPT treats it as Critical, and so should you. SSH must also refuse empty passwords.

Root should not log in over SSH at all. Named users log in and then use sudo. That keeps a record of which person acted.

Lockout limits guessing. PAM faillock locks an account for a while after a few failed attempts. SSH adds MaxAuthTries and a short LoginGraceTime.

Password logins over SSH should be the exception. Where they remain, AuthenticationMethods can require a key as well, so a stolen password alone is not enough.

What They May Do: Sudo

Sudo is where authorisation is written down. Each rule says which user may run which commands as which target user.

NOPASSWD removes the second proof. Any process running as that user, including a hijacked web application, becomes root with one command.

Sudo should run commands in a pseudo-terminal and log to its own file. Then privileged actions are recorded and cannot linger after the session ends.

Separation of duties means the person who approves a change is not the only person who can make it. On a small server, sudo logs are often the only evidence of who did what.

The Files That Define Access

Access control is only as strong as the files that store it. /etc/passwd and /etc/group must not be writable by others, or anyone can add a root account.

/etc/shadow and /etc/gshadow hold password hashes and must not be readable by others. A readable shadow file turns every local user into an offline password cracker.

Duplicate user ids give two names the same rights. Legacy '+' NIS entries can import accounts from elsewhere. Trust files such as .rhosts and .netrc grant access or hold passwords in plain text.

The default umask decides who can read every new file. With 022 every new file is readable by every local user. 027 or stricter keeps new files private by default.

In Summary

Authentication proves identity and authorisation grants rights. Close every login path that is not needed. Keep sudo rules specific, with a password and a log. Protect the files that store accounts and passwords, and set a strict umask.

Apply It

These OpenVAPT checks put this module into practice. Open one to see its detection logic and source code.

Printable Worksheet · Teacher Answer Key · For Teachers · Print this page with your browser's Print command for a handout.

Also available as plain Markdown for notes, scripts and AI tools. Same facts, same source, no styling.

Lab

1. Run: openvapt demo --only HOST-USR-,HOST-PWD-,HOST-SUDO-,HOST-SSH-001,HOST-SSH-003,HOST-FS-001 --out p15
2. For each failed check, write one line: who gets in, or what they can do, that they should not.
3. Run: openvapt explain HOST-PWD-004 and read how pam_faillock is detected in both PAM positions.
4. On your own machine: awk -F: '$7 !~ /nologin|false/ {print $1}' /etc/passwd and ask why each listed account needs a shell.
5. On your own machine: sudo -l and read your own sudo rules. Which ones carry NOPASSWD, and why?

Check Yourself

Answers are checked in your browser and never stored or sent.

References

• NIST SP 800-53 Rev. 5, Security and Privacy Controls (AC and IA families)
• NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management
• sudoers(5) manual
• pam_faillock(8) manual

Adapted from the OpenVAPT Academy (openvapt.com), built by AI Cybersecurity Engineers, used under the OpenVAPT Source-Available Licence 1.3. Free teaching use under Teaching With OpenVAPT. Pre-release material may be wrong or unstable; use at your own risk.

OpenVAPT. (2026). P15: Access Control: Accounts, Sudo and Logins (Version 0.1.0-alpha.6). OpenVAPT Academy. Retrieved October 16, 2026, from https://openvapt.com/academy/p15.html

@misc{openvapt_p15,
  author       = {{OpenVAPT}},
  title        = {{P15: Access Control: Accounts, Sudo and Logins}},
  year         = {2026},
  howpublished = {\url{https://openvapt.com/academy/p15.html}},
  note         = {OpenVAPT Academy, version 0.1.0-alpha.6. Accessed 16 October 2026}
}