L5. Users, Groups and the Root Account

Why User Management Matters for Security

Every process on a Linux system runs as a specific user. Every file is owned by a specific user. The permission system that controls who can read, modify, or execute anything on the system is built on user and group identities. If you do not understand user management, you cannot understand Linux access control.

From an attacker's perspective, the first question after gaining a foothold is: "What user am I, and what can this user do?" From a defender's perspective, the job is to ensure that each user (and each service) has the minimum permissions needed and nothing more.

User Account Fundamentals

The /etc/passwd File

Every user account on the system has an entry in /etc/passwd. Despite the name, this file does not store passwords (not anymore). It stores account metadata.

cat /etc/passwd

Each line follows this format:

username:x:UID:GID:comment:home_directory:shell

Example entries:

root:x:0:0:root:/root:/bin/bash
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
idan:x:1000:1000:Idan Ohayon:/home/idan:/bin/bash

Key fields:

Security note: Service accounts like www-data, mysql, and nobody have their shell set to /usr/sbin/nologin or /bin/false. This prevents anyone from using these accounts to log in interactively, even if the account is compromised.

The /etc/shadow File

Actual password hashes are stored in /etc/shadow, which is readable only by root:

sudo cat /etc/shadow

Format:

username:$hashed_password:last_changed:min:max:warn:inactive:expire

Example:

idan:$6$rounds=5000$salt$hash...:19528:0:99999:7:::

The hash prefix indicates the algorithm:

If the password field contains ! or *, the account cannot log in with a password.

Managing Users

Creating Users

# Create a user with a home directory and default shell
sudo useradd -m -s /bin/bash newuser
# Set a password for the new user
sudo passwd newuser
# Create a user in one step with additional details
sudo useradd -m -s /bin/bash -c "Security Analyst" -G sudo analyst

The -m flag creates the home directory. The -G flag adds the user to supplementary groups (in this case, the sudo group).

Modifying Users

# Change a user's shell
sudo usermod -s /bin/zsh idan
# Add a user to a group (without removing existing groups)
sudo usermod -aG docker idan
# Lock a user account (disable login)
sudo usermod -L suspicioususer
# Unlock a user account
sudo usermod -U suspicioususer

Important: Always use -aG (append to groups) when adding a user to a new group. Using -G without -a replaces all existing group memberships, which could lock the user out of critical groups.

Deleting Users

# Delete a user but keep their home directory
sudo userdel olduser
# Delete a user and their home directory
sudo userdel -r olduser

Security note: When an employee leaves the organization, you should disable the account immediately (usermod -L) and archive the home directory before deletion. Deleting the home directory destroys potential evidence that might be needed for investigations.

Groups

Groups allow you to assign permissions to multiple users at once. Instead of giving each user individual access to a shared directory, you create a group, add the users, and assign permissions to the group.

Key Group Commands

# View current user's groups
groups
# View any user's groups
groups idan
# View detailed user identity information
id idan
# Create a new group
sudo groupadd security-team
# Add a user to a group
sudo usermod -aG security-team idan
# Delete a group
sudo groupdel old-group

The id command shows the user's UID, primary GID, and all supplementary groups:

uid=1000(idan) gid=1000(idan) groups=1000(idan),27(sudo),999(docker)

Important System Groups

Security warning: Adding a user to the docker group gives them the ability to run containers with root-level access to the host filesystem. Treat docker group membership as equivalent to granting root access.

The Root Account

The root account (UID 0) has unlimited power on the system. It can read any file, kill any process, modify any configuration, and bypass almost all permission checks.

Why You Should Not Use Root Directly

1. No audit trail: If multiple administrators share the root password and log in as root, you cannot determine who performed a specific action.
2. No safety net: A typo as root can destroy the entire system. There is no "are you sure?" prompt for most commands.
3. Accountability: Security compliance frameworks (SOC 2, PCI-DSS, HIPAA) require individual accountability for administrative actions.
4. Blast radius: If an attacker compromises a root session, they own the entire system immediately. If they compromise a regular user, there is still a privilege escalation barrier.

The Right Approach: sudo

Instead of logging in as root, use your regular account and prefix privileged commands with sudo. This gives you:

• Logging: Every sudo command is logged (typically in /var/log/auth.log or /var/log/secure)
• Granularity: You can configure which users can run which commands as root
• Time-limited: sudo authentication expires after a few minutes, reducing the window of exposure

We will cover sudo configuration in depth in Lesson 7.

Checking Root Login Status

# Check if root login is enabled via password
sudo grep "^root" /etc/shadow
# Check if root SSH login is allowed
grep "PermitRootLogin" /etc/ssh/sshd_config

On a hardened system, root should not have a usable password, and SSH root login should be set to no.