Security modules, capabilities, and remote access
Beyond basic permissions, Linux offers finer-grained privileges, mandatory access control, and secure remote login. Together they implement defence in depth.
Capabilities
Traditionally, root could do everything and everyone else very little. Linux capabilities split root's power into about 40 distinct privileges, such as CAP_NET_BIND_SERVICE (bind to ports below 1024), CAP_SYS_ADMIN (broad administration), and CAP_NET_RAW (raw sockets). A program can be granted only the capabilities it needs, for example setcap cap_net_bind_service=+ep /usr/local/bin/server, instead of running as root.
Discretionary and mandatory access control
Standard Unix permissions are discretionary: owners decide who may access their files. Mandatory access control (MAC) adds system-wide policies that even owners and root processes cannot override. If a web server is compromised, MAC can stop it from reading home directories or opening unexpected network connections, even though normal permissions might allow it.
SELinux and AppArmor
SELinux, originally developed by the US National Security Agency and merged into the kernel in 2003, labels every process and file with a security context and enforces detailed type-enforcement policies; it is enabled by default on Red Hat, Fedora, and related systems. AppArmor, default on Ubuntu and SUSE, confines programs using path-based profiles that are easier to write. Both have enforcing and permissive or complain modes.
SSH
Secure Shell (SSH), created by Tatu Ylonen in 1995, provides encrypted remote login, command execution, and file transfer; OpenSSH is the standard implementation. ssh user@host logs in; scp and sftp copy files; ssh -L and -R forward ports through encrypted tunnels. Servers listen on port 22 by default and are configured in /etc/ssh/sshd_config.
Key-based authentication
Instead of passwords, SSH can use key pairs. ssh-keygen -t ed25519 creates a private key, kept secret and ideally protected by a passphrase, and a public key, which is added to ~/.ssh/authorized_keys on servers. The server verifies that the client holds the private key without it ever being sent. Disabling password logins (PasswordAuthentication no) defeats password-guessing attacks.
Hardening SSH
Common SSH hardening includes disallowing direct root login (PermitRootLogin no), requiring keys, limiting which users may log in, using fail2ban or rate limits to block repeated failures, keeping OpenSSH updated, and verifying host keys on first connection to avoid man-in-the-middle attacks. Multi-factor authentication via PAM adds another layer for sensitive systems.
Auditing and accountability
The audit subsystem (auditd) can record security-relevant events such as file accesses, privilege changes, and system calls. Authentication events appear in the journal and in /var/log/auth.log or /var/log/secure. last and lastb list recent and failed logins. Good logging supports investigations and compliance.
Worked example
Setting up key login to a server: on the laptop, ssh-keygen -t ed25519 -C 'ana laptop' creates ~/.ssh/id_ed25519 and id_ed25519.pub; ssh-copy-id ana@server.example appends the public key to the server's authorized_keys; ssh ana@server.example now logs in without a password. After confirming this works, the administrator sets PasswordAuthentication no and PermitRootLogin no in sshd_config and reloads sshd with systemctl reload ssh.
Key takeaways
Capabilities divide root's power into specific privileges, such as CAP_NET_BIND_SERVICE, granted with setcap. Discretionary permissions are owner-controlled; mandatory access control enforces system-wide policies even on root processes. SELinux (NSA-originated, merged 2003; default on Red Hat and Fedora) labels processes and files; AppArmor (Ubuntu, SUSE) uses path-based profiles. SSH (1995; OpenSSH) gives encrypted login, file copy, and tunnels on port 22. Ed25519 key pairs with authorized_keys replace passwords. Harden SSH by disabling root and password login, rate limiting, updating, and verifying host keys. auditd and authentication logs provide accountability.
Flashcard
Fine-grained pieces of root's power
Check your understanding
A web server needs to listen on port 443 but should not run as root. What is a suitable approach?