Understanding User Permissions: Your First Line of Defense - Part 3 of 5 of the Terminal Techniques for You (TTY): Making Linux Security Accessible Blog Series

Welcome to the third installment of our TTY series! Previously we learned how to navigate the Linux file system and keep our software updated. In this post we're going to explore one of the most fundamental security features of Linux: the permission system.

Linux was designed from the ground up with multiple users in mind, unlike early personal computer operating systems where anyone with physical access could do virtually anything. This multi-user design creates natural security boundaries that, once understood, form a powerful protection system for your files and system resources.

The Philosophy Behind Linux Permissions

At its core, Linux security is built on a simple question: "Who is allowed to do what?" The permission system answers this by creating clear boundaries between:

1. Users (who owns what)
2. Actions (what can be done)
3. Resources (what is being accessed)

This separation serves a critical security function: even if one account is compromised, the damage can be contained. It's like having multiple secure rooms in a building rather than one open warehouse—a breach in one room doesn't automatically grant access to the others.

Users and Groups: The "Who" of Permissions

Before we dive into permission commands, let's understand the two entities permissions apply to:

Users

Every person who uses a Linux system has a user account, which includes:

• A unique username (like "sec406")
• A unique user ID number (UID)
• A home directory (typically /home/username)
• A default group

You can see your own user information with:

$ whoami

sec406

$ id

uid=1000(sec406) gid=1000(sec406) groups=1000(sec406),4(adm),24(cdrom),27(sudo)

The `id` command shows your user ID (uid), primary group ID (gid), and any additional groups you belong to.

Groups

Groups are collections of users that share certain permissions on system resources. Every user belongs to at least one group (their primary group) but can belong to many.

To see all groups you belong to:

$ groups

sec406 adm cdrom sudo

In this example, user "sec406" belongs to four groups, including the "sudo" group which grants administrator privileges.

The Three Permission Types: The "What" of Permissions

Linux defines three basic actions that can be permitted/allowed or restricted/denied:

1. Read (r): View file or directory contents
2. Write (w): Modify files or create/delete files in directories
3. Execute (x): Run files as programs or access directory contents

These mean different things depending on whether you’re dealing with a file or a directory:

For files:

• r - View the file's contents
• w - Modify the file
• x - Run the file as a program

For directories:

• r - List directory contents
• w - Create, rename, or delete files within a directory
• x - Access files or traverse the directory

The execute permission on directories is particularly important and often confuses beginners. If a user does not have the execute permission on a directory, that user cannot:

• Access any files inside it, even if you know their names
• Use the directory in paths, as in path traversals, even if you have read permission

The Three Permission Categories: The "Who" in Detail

Every file and directory has permissions divided into three categories:

1. User (sometimes referred to as Owner): The file’s owner (usually the creator)
2. Group: Users who are members of the file's group
3. Others (sometimes referred to as World): Everyone else on the system

When you list files with `ls -l`, you see these permissions in the first column:

$ ls -l

total 16

-rw-r--r-- 1 sec406 users 2048 Feb 27 15:40 report.txt

drwxr-xr-x 2 sec406 users 4096 Feb 27 15:30 scripts

Let's decode `-rw-r--r--` (for "report.txt"):

• `-` = regular file
• `rw-` = owner (sec406) read/write, no execute
• `r--` = group (users) read-only
• `r--` = others can read

So, for this file:

• sec406 (the user owner) can read and write the file
• Members of the "users" group can only read it
• Everyone else has read only permissions on it

For the "scripts" directory: `drwxr-xr-x`

• `d` = directory
• `rwx` = owner has full permissions (read/write/execute)
• `r-x` = group (users) can read and execute (list contents and access the directory)
• `r-x` = others can read and execute

Viewing Permissions in Action

Let's see how these permissions work in practice:

$ echo "This is a test file." > test.txt

$ ls -l test.txt

-rw-rw-r-- 1 sec406 sec406 20 Feb 27 17:00 test.txt

By default, new files typically get permissions allowing the user owner and group owner to read and write, while others can only read.

Let's test these permissions by switching to another user:

$ su - lab

Password:

$ cat /home/sec406/test.txt

This is a test file.

$ echo "Adding a line" >> /home/sec406/test.txt

-bash: /home/sec406/test.txt: Permission denied

This demonstrates how permissions protect files from unauthorized modification.

Changing File Permissions with chmod

To change permissions, we use the `chmod` command. There are two ways to specify permissions:

Symbolic Method

The symbolic method uses letters to specify:

• Who: `u` (user/owner), `g` (group), `o` (others), `a` (all)
• Operation/Operator: `+` (add), `-` (remove), `=` (set exactly)
• Permissions: `r` (read), `w` (write), `x` (execute)

Examples:

$ chmod u+x script.sh

$ chmod o-w test.txt

$ chmod a+rx program

$ chmod u=rwx,g=rx,o=rx file

#### Octal (or Numeric) Method

The octal/numeric method uses numbers to represent permission combinations:

• Read (r) = 4
• Write (w) = 2
• Execute (x) = 1

By adding these values, we create a single digit for each category:

• No permissions = 0
• Execute only = 1
• Write only = 2
• Write and execute = 3
• Read only = 4
• Read and execute = 5
• Read and write = 6
• Read, write, and execute = 7

Using this method, we specify three digits for the user owner, group owner, and others:

$ chmod 754 script.sh

$ chmod 640 private.txt

$ chmod 700 secretfolder

The numeric method is shorter but requires calculating the values. The symbolic method is more intuitive for making specific changes.

Common Permission Patterns

Here are some common permission patterns you'll use:

• `chmod 755 file` (rwxr-xr-x): Scripts and programs everyone can execute
• `chmod 644 file` (rw-r--r--): Regular files that everyone should be able to read
• `chmod 700 directory` (rwx------): A "private" directory that only the user owner can access
• `chmod 750 directory` (rwxr-x---): A "semi-private" directory the user owner and group owner can access but others cannot
• `chmod 777 file` (rwxrwxrwx): Everyone has full access (generally AVOID this for security reasons)

Changing File Ownership with chown

Permissions are tied to users and groups and sometimes you may need to change ownership with the `chown` command:

$ sudo chown lab file.txt

$ sudo chown lab:developers file.txt

You'll need administrator privileges (`sudo`) to change the ownership of files you don't own.

To change only the group owner, you can use:

$ sudo chgrp developers file.txt

To change ownership recursively for a directory and all its contents:

$ sudo chown -R sec406:users project_directory/

Special Permissions: Advanced Features

Beyond the basic permissions, Linux has three special permission bits.

SetUID (SUID)

When set on an executable file, it runs with the permissions of the file's user owner, not as the user who executes it.

$ sudo chmod u+s executable

$ sudo chmod 4755 executable# The 4 represents the SUID bit

You'll recognize files with SUID by an "s" in the user owner's execute position:

$ ls -l /usr/bin/passwd

-rwsr-xr-x 1 root root 68208 Apr 16  2020 /usr/bin/passwd

The `passwd` command needs SUID because regular users need to update files owned and writeable by the root user.

SetGID (SGID)

SetGID has two uses:

1. On executables: runs with group permissions (it's like you become a member of the group, only while the executable is running)
2. On directories: New files and directories created inside inherit the group (great for team collaboration or shared directories)

$ sudo chmod g+s directory

$ sudo chmod 2775 directory# The 2 represents the SGID bit

Files with SGID have an "s" in the group's execute position:

$ ls -ld /shared_directory

drwxrwsr-x 2 root developers 4096 Feb 27 17:30 /shared_directory

Sticky Bit

When set on a directory, the sticky bit restricts file deletion. Only the file's user owner, directory owner, or root can delete files, even if others have write permissions on the directory.

$ sudo chmod +t directory

$ sudo chmod 1777 directory# The 1 represents the sticky bit

Directories with the sticky bit have a "t" in the others execute position:

$ ls -ld /tmp

drwxrwxrwt 19 root root 4096 Feb 27 17:45 /tmp

The `/tmp` directory is world-writable but has the sticky bit set. This means users can only delete their own files.

Real-World Permission Scenarios

Let's look at how to apply permissions in common scenarios:

Personal Private Files

For files only you should access:

$ chmod 600 ~/.ssh/id_rsa# SSH private key

$ chmod 600 ~/.config/passwords# Any sensitive configuration file

Shared Project Directory

For a directory where your team needs shared access:

$ sudo groupadd project_team

$ sudo usermod -a -G project_team sec406

$ sudo usermod -a -G project_team lab

$ sudo mkdir /projects/team_project

$ sudo chown sec406:project_team /projects/team_project

$ sudo chmod 770 /projects/team_project# Team has full access, others none

$ sudo chmod g+s /projects/team_project# New files inherit group

Web Server Content

For files that a web server needs to access:

$ sudo find /var/www/html -type f -exec chmod 644 {} \;# Regular files

$ sudo find /var/www/html -type d -exec chmod 755 {} \;# Directories

$ sudo chown -R www-data:www-data /var/www/html# Web server ownership

Executable Scripts

For scripts you want to run:

$ chmod 744 ~/scripts/backup.sh# Executable by the user owner, readable by the group owner and others

Permission-Related Vulnerabilities

Even with a solid understanding of permissions, there are several common security mistakes to avoid.

Excessive Permissions

The most common mistake is giving more permissions than necessary:

$ chmod 777 file.txt# Everyone can do everything

This is like leaving your house with all doors and windows open with a sign welcoming everyone into your home where they can eat all your food and take all your things. Seriously, heed the warning!

World-Writable Files and Directories

Files that anyone can modify are security risks:

$ find ~ -type f -perm -o=w -not -path "/proc/*" 2>/dev/null

Review and fix these permissions:

$ chmod o-w dangerous_file.txt

Insecure Home Directory

By default, many Linux distributions create home directories with permissive settings (755). Consider using more restrictive permissions:

$ chmod 750 /home/yourusername

This allows you to access everything, your group to list files, and blocks access from others.

Unprotected Configuration Files

Configuration files often contain sensitive information:

$ ls -la ~/.ssh/

$ chmod 600 ~/.ssh/id_rsa

$ chmod 600 ~/.ssh/id_ed25519

Default Permissions with umask

The `umask` command sets default permissions for newly created files and directories:

$ umask

0022

The umask value is subtracted from the maximum default permissions (666 for files, 777 for directories):

• - With umask 022: files get 644 (`rw-r--r--`), directories get 755 (`rwxr-xr-x`)
• - With umask 077: files get 600 (`rw-------`), directories get 700 (`rwx------`)

To set a more restrictive umask:

$ umask 077# For the current session

To make it permanent, add it to your shell's configuration file (like ~/.bashrc).

Practical Exercise: Security Audit

Let's perform a simple permission audit on your system.

1. Check your home directory permissions:

$ ls -ld ~

2. Find world-writable files in your home directory:

$ find ~ -type f -perm -o=w -not -path "*/\.*" 2>/dev/null

3. Check permissions on important configuration directories:

$ ls -la ~/.ssh/

$ ls -la ~/.config/

4. Find files with special permissions:

$ find ~ -type f -perm -6000 2>/dev/null

5. Review and fix any issues found:

          # Example fix for an overly permissive file

$ chmod 600 ~/sensitive_document.txt

Access Control Lists (ACLs): Beyond Basic Permissions

For more complex access requirements, Linux offers ACLs. These allow you to specify permissions for multiple users and groups beyond the traditional user/group/others model:

$ sudo apt install acl

$ setfacl -m u:lab:r file.txt

$ getfacl file.txt

Files with ACLs have a "+" at the end of their permission string in `ls -l` output.

$ ls -l file.txt

-rw-rw-r--+ 1 sec406 users 3119 Apr 16  2020 file.txt

Checking Your Effective Permissions

Sometimes it's unclear what your effective permissions are, especially with complex setups. The `id` command we saw earlier helps determine which groups you belong to:

$ id

uid=1000(sec406) gid=1000(sec406) groups=1000(sec406),4(adm),27(sudo)

To see if you have write access to a specific file:

$ [ -w filename ] && echo "Writable" || echo "Not writable"

The `||` means "run the second command only if the first one fails."

Applying Permissions Correctly: A Checklist

Here's a checklist to help you apply permissions correctly:

1. Identify Data Sensitivity: How sensitive is the data? Who needs access?
2. Apply Least Privilege: Give only the permissions necessary
3. Check Recursively: For directories, ensure all contained files have appropriate permissions
4. Verify Group Membership: Make sure users are in the correct groups
5. Test Access: Verify that permissions work as expected
6. Review Regularly: Permissions may need to change as needs evolve

Permissions as Your Security Foundation

Understanding Linux permissions is more than memorizing commands—it's about developing a security mindset. The principle of least privilege, giving users and processes only the access they absolutely need, is fundamental to system security.

By mastering permissions, you've completed another important step in your Linux security journey. You now know how to:

• View and interpret permissions
• Change permissions with `chmod`
• Change ownership with `chown`
• Use special permissions
• Identify common permission-related vulnerabilities
• Set default permissions with `umask`

Remember, proper permissions are a fundamental line of defense. They won't stop all attacks, but they make unauthorized access much more difficult.

Practice Questions

To reinforce your learning, answer these questions:

1. If a file has permissions `-rw-r-----`, what numeric value (octal) would you use with chmod to set these exact permissions?
2. What command would you use to allow group members to read/write a file, but block others?
3. When would you use the SetGID bit on a directory, and what effect does it have?
4. What command would you use to secure a file with 777 permissions while ensuring you can still use it?
5. What's the difference between `chmod 700` and `chmod 500` on a directory? When might you use each?

Want to know more? Check out the course preview of SEC406^TM: Linux Security for InfoSec Professionals^TM for a free hour of course content.

Ready to take your Linux skills to the next level? For a limited time, take SEC406 for just $5,250!