User Avatar

Lesson Menu

Linux Security

Secure Practices Guide

Introduction: Why Dedicated Users & Groups?

When running scripts or applications on a Linux server, especially those that interact with the system or manage data, it's crucial to operate under the **Principle of Least Privilege**. This means any given process should only have the permissions absolutely necessary to perform its tasks, and no more.

Creating dedicated, non-privileged users and groups for your scripts is a fundamental security practice. It helps isolate processes, limit potential damage if a script is compromised, and provides clearer audit trails.

Core Security Goal: Minimize the attack surface and the potential impact of a security breach by restricting what a compromised script or application can do.

Step 1: Creating a New User

The first step is to create a dedicated user account that your script or application will run as. This user should typically be a "system" user, often without a login shell or a standard home directory, to further restrict its capabilities.

Using adduser (Recommended & Interactive)

sudo adduser --system --no-create-home --group your_script_user
  • sudo: Executes the command with superuser privileges.
  • adduser: A user-friendly command to add users.
  • --system: Creates a system user. These users typically have UIDs in a lower range and are not intended for interactive login.
  • --no-create-home: Prevents the creation of a home directory in /home/. Often, scripts don't need a traditional home directory.
  • --group: Also creates a group with the same name as the user (your_script_user) and adds the user to it. This is convenient.
  • your_script_user: Replace this with the desired username for your script (e.g., webapp_runner, backup_script_svc).

Using useradd (Low-level Alternative)

sudo useradd -r -s /usr/sbin/nologin -M your_script_user
  • useradd: A low-level utility for creating users.
  • -r: Creates a system account.
  • -s /usr/sbin/nologin (or /bin/false): Sets the user's shell to a non-interactive shell, preventing direct login.
  • -M: Do not create the user's home directory.

After using useradd, you might need to create a group separately and assign the user to it if that's not your system's default behavior.

Security Benefit: Isolation & Least Privilege

If your script (running as your_script_user) gets compromised (e.g., through a vulnerability), the attacker only gains the permissions of your_script_user. This user should have no sudo rights and minimal access to system files. This is far better than if the script ran as root or your personal user account, where a compromise could lead to full system control.

Step 2: Creating a New Group (If Needed)

Often, adduser --group (or your system's useradd defaults) will create a primary group for the new user. However, you might want to create a separate, shared group if multiple script users or specific services need to access a common set of resources.

Command

sudo groupadd your_app_group
  • groupadd: The command to create a new group.
  • your_app_group: Replace with your desired group name (e.g., web_content_editors, data_processors).

Security Benefit: Granular Access Control

Groups allow you to define collective permissions for a set of users. Instead of giving individual users direct permissions to many files, you grant permissions to the group. This simplifies management and ensures that users only get access to shared resources relevant to their group's role.

Step 3: Adding a User to a Group

If you created a separate application group (like your_app_group) and want your script user to be a member (in addition to its own primary group), use the usermod command.

Command

sudo usermod -a -G your_app_group your_script_user
  • usermod: Modifies a user account.
  • -a (append): Crucial! This adds the user to the specified supplementary group(s) *without* removing them from existing groups.
  • -G: Specifies the list of supplementary groups.
  • your_app_group: The group to add the user to.
  • your_script_user: The user to modify.

Security Benefit: Role-Based Access

Adding users to specific groups allows for a clear, role-based access control model. The script user (your_script_user) has its own minimal identity, and its membership in your_app_group grants it the specific privileges associated with that group's role, nothing more.

Step 4: Setting File Ownership & Permissions

Once your user and group are set up, you need to ensure that the script itself, its configuration files, data directories, and any other related resources are owned by this user/group and have appropriate (minimal) permissions.

Changing Ownership (chown)

sudo chown your_script_user:your_app_group /srv/yourapp/data/some_file.txt sudo chown -R your_script_user:your_app_group /srv/yourapp/nodes_data_directory/
  • chown: Changes file owner and group.
  • your_script_user:your_app_group: Sets the owner to your_script_user and the group to your_app_group.
  • -R (Recursive): Applies the ownership change to all files and directories within the specified directory. Use with caution.

Changing Permissions (chmod)

Permissions are set for Owner, Group, and Others (UGO).

  • For a data file the script needs to read/write: sudo chmod 640 /srv/yourapp/data/some_file.txt (Owner: Read/Write; Group: Read-only; Others: No access)
  • For a script file that needs to be executed by the owner: sudo chmod 750 /srv/yourapp/scripts/my_script.sh (Owner: Read/Write/Execute; Group: Read/Execute; Others: No access)
  • For a directory the script needs to access and manage files within: sudo chmod 750 /srv/yourapp/nodes_data_directory/ (Owner: RWX; Group: RX; Others: No access) sudo chmod 640 /srv/yourapp/nodes_data_directory/* (for files inside)

The exact permissions (e.g., `640`, `750`) depend on the specific needs of your script. Always aim for the most restrictive permissions that still allow the script to function correctly.

Security Benefit: Controlled Access & Integrity

Correct file ownership and permissions ensure that only the designated your_script_user (and members of your_app_group, if applicable) can access or modify the script's files and data. This prevents unauthorized users or other processes on the system from tampering with your script's operation, reading sensitive data it handles, or exploiting it to gain further access.

Conclusion

Creating dedicated users and groups for your scripts and meticulously managing file ownership and permissions are cornerstone practices for Linux server security. By adhering to the Principle of Least Privilege:

  • You significantly **reduce the potential impact** of a script compromise.
  • You **isolate processes**, preventing unintended interactions.
  • You create a **more auditable and manageable system**.

While it adds a few extra steps to your setup, the security benefits far outweigh the initial effort, especially for applications handling sensitive data or performing critical system tasks.

Next Lesson >> (7ioSM Admin Panel)