permissions

Overview

Hardening a Linux system means auditing and tightening permissions and ownership so that files and privileges follow least privilege. This lesson applies the permissions module to practical hardening.

Learning objectives

• Audit permissions for hardening weaknesses.
• Identify and fix over-permissive and misowned files.
• Apply least privilege to files, directories, and privileges.

Core concept

Permission hardening focuses on removing unnecessary access:

• Eliminate world-writable files/directories where not required (a common, dangerous weakness).
• Restrict sensitive files — secrets, keys, and configs should be readable only by the accounts that need them (e.g. private keys 600).
• Verify ownership — sensitive files should be owned by the correct, minimal-privilege account.
• Audit setuid/setgid binaries — enumerate them and remove the bit from any that do not truly need it.
• Limit privileged access — minimize sudo/powerful-group membership.

How it works

Hardening starts with auditing: enumerate over-permissive files (e.g. find / -perm -002 -type f for world-writable files), setuid binaries (find / -perm -4000), and check ownership on sensitive paths. Then apply least privilege — tighten permissions with chmod, fix ownership with chown, and remove needless special bits. Each removed excess permission is an avenue closed. This mirrors the least-privilege principle applied systematically across the filesystem and privilege model.

Practical example

An audit finds a configuration file containing credentials that is world-readable (-rw-r--r--) and a custom setuid-root helper script that does not need elevation. Hardening: chmod 640 (or 600) the config and set its owner/group appropriately so only authorized accounts read it, and remove the setuid bit from the script (chmod u-s). Both changes shrink the attack surface and close potential privilege-escalation paths.

Cybersecurity relevance

Permission and ownership weaknesses are among the most common findings in Linux assessments and a frequent basis for privilege escalation: world-writable files that are executed by privileged processes, readable secrets, and unnecessary setuid-root binaries can each hand an attacker more access. Systematically auditing and tightening these — the defensive counterpart to what testers hunt for — meaningfully raises the difficulty of compromise and containment after a foothold.

Common mistakes

• Leaving world-writable files/directories in place, enabling tampering.
• Overlooking setuid/setgid binaries during hardening, missing escalation paths.
• Fixing permission bits but not ownership (or vice versa), leaving the wrong account in control.

Key takeaways

• Permission hardening audits and tightens access: remove world-writable files, restrict secrets/keys (e.g. 600), verify ownership, and minimize setuid/setgid binaries.
• Use enumeration (find -perm ...) to locate weaknesses, then apply least privilege with chmod/chown.
• These weaknesses are common privilege-escalation findings; systematically closing them is the defensive counterpart to offensive privilege hunting.

Check your understanding

• Why are world-writable files and unnecessary setuid-root binaries hardening concerns?
• What two attributes (besides the permission bits) should you verify when hardening a sensitive file?