Linux uses a user-based security model where every process runs under the context of a user. Some key points about Linux users:
Each user is assigned a unique user ID (UID). The first user created has a UID of 0 and is called root.
Users belong to groups that share similar permissions. Each user has a primary group and can belong to multiple secondary groups.
Users are assigned a home directory that is owned by that user. For example, /home/john for the user john.
Users have permission to read, write and execute files based on the file's ownership and permissions.
There are different types of users:
Regular users - Have limited privileges and capabilities.
System users - Used by system services and daemons. They have no login shell.
Admin users - Have elevated privileges to perform system administration tasks.
Root user - The superuser with full privileges and control over the system.
Users are created using the useradd command and deleted using userdel.
Users can be assigned a login shell (bash by default) or no login shell (nologin or false).
Users passwords are stored in an encrypted format in /etc/shadow. Only root can read this file.
sudo is used to temporarily elevate a user's privileges to perform administrative tasks.
su is used to switch to another user (usually root) and run commands as that user.
In summary, Linux's user-based security model isolates processes and limits their capabilities based on which user owns them. This separation of users is a fundamental part of Linux's multi-user architecture and security design.
Root user
The root user in Linux is a special user that has complete and unlimited access to the entire system. Some key points about the root user:
The root user's username is "root" and its user ID (UID) is 0.
Root has full privileges and can perform any administrative task on the system. There are no restrictions on what root can do.
Root can read, write and execute any file, regardless of its permissions.
Root owns all the important system files and directories like /bin, /sbin, /etc, /var, etc.
Root can run any program, access any device, and modify any system configuration file.
Root is the only user that is allowed to change the permissions and owners of files.
Root is considered a "super user" with ultimate power over the system.
You should only login and use the root account when necessary to perform administrative tasks.
It is good practice to use the "sudo" command instead of logging in as root directly. This leaves an audit trail and requires the user's password.
Root's password is stored in the /etc/shadow file which only root can read. This protects the root password hash.
Root should have a strong password and the root account should be locked down as much as possible.
In case root's password is lost or forgotten, Linux provides ways to reset it via a rescue disk or live USB.
In summary, the root user has been given complete control over the system to perform any administrative task. However, due to its power, the root account should be used with extreme caution and only when necessary. Using sudo instead of su to root is considered a more secure practice.
File Security
Here are the main aspects of file security in Linux:
Permissions: Each file and directory has read, write and execute permissions for the owner, group and others. These permissions control who can access the file and how.
Ownership: Each file belongs to an owner (user) and a group. The owner and group can control the permissions of the file.
umask: A mask that determines the default permissions for newly created files. It filters out some permissions by default for security.
Sticky bit: A special permission bit that allows a file to be deleted or modified only by its owner, the root user, or the owner of the directory it's in. Used for /tmp and other shared directories.
SELinux: An additional layer of security that confines users and processes to domains. It can further restrict access to files based on security contexts.
Access Control Lists (ACLs): A more fine-grained permission system that allows specifying access for multiple users and groups on a single file.
Encryption: Encrypting files at rest using tools like OpenSSL, GPG or VeraCrypt adds another layer of security. Only users with the decryption key can access the file contents.
Mandatory Access Control (MAC): Policies enforced by the kernel to ensure that system and security rules are always followed when accessing files.
In summary, Linux provides a robust set of features to control access to files at different levels. The combination of permissions, ownership, umask, SELinux, ACLs, encryption and MAC policies gives administrators a lot of flexibility in implementing the principle of least privilege for file security.
The key is to configure these features appropriately based on the sensitivity of the files and the intended access for users and processes.
Best Practice
Here are some best practices to organize users and implement file security on Linux:
Create separate user accounts for each person and system service. Do not share accounts.
Assign each user the minimum privileges they need to perform their tasks. Follow the principle of least privilege.
Use group memberships to assign common privileges to multiple users. Create separate groups for different roles.
Use umasks that block unnecessary permissions by default for new files. A umask of 027 is a reasonable default.
Use ACLs on critical files and directories to grant more granular access to specific users and groups.
Enable SELinux or AppArmor to further confine users and processes to specific domains. This adds an extra layer of security.
Encrypt sensitive files at rest using tools like VeraCrypt or GPG. Only authorize users with the decryption key can access the contents.
Assign file ownerships appropriately. Files and directories that are meant to be shared should be owned by a designated group, not an individual user.
Use the sticky bit on shared directories like /tmp to restrict file deletions and modifications.
Regularly check and correct any permission or ownership issues. Use tools like
findandchgrpto identify and fix problems.Educate users about basic Linux file security and permissions. Explain why certain restrictions are in place.
Audit file access using tools like
auditdto detect any anomalies and security issues. Take corrective action when needed.
In summary, the combination of assigning proper ownerships and permissions, using umasks, ACLs, encryption, SELinux/AppArmor, sticky bits and auditing can help you implement a secure configuration for file access and management on Linux. Let me know if you have any other questions!
Default Access
When a new user is created on Linux, here are the default folders and access for that user:
A home folder is created for the user, usually at /home/username. The user has full read, write and execute access to this folder.
The user's default shell is initialized, usually bash. The shell startup files like .bashrc and .bash_profile are created in the home folder.
The user has no access by default to system folders like /bin, /sbin, /etc, /var, /opt, /usr/etc. The user needs root privileges to access these folders.
The user has read access to some shared folders like /tmp and /var/tmp. But the user cannot modify or delete files created by other users in these folders by default.
The user has no access to other users' home folders by default. The user needs to be added to that user's group to gain access.
The user's umask is initialized, usually 002 or 022, which blocks write access for group and others to newly created files by the user.
The user has no access to NFS mounted network shares by default. The user needs to be granted access permissions on the NFS server.
The user's mailbox is created under /var/spool/mail and the user gains read and write access to it. The user can read incoming emails and compose new ones.
The user has no access to devices like /dev/sda1, /dev/hda etc. The user needs to be granted access using udev rules.
So in summary, when a new user is created, the main things that happen are: a home folder is created, a default shell is initialized, some default umask is set and access is granted to the user's mailbox. But by default, no access is given to system folders, other users' folders or devices. The administrator needs to grant those accesses explicitly.
File Properties
Linux files and folders have several properties that provide information about them:
Permissions: Specify who can read, write and execute the file. Stored as rwx rwx rwx. First group of 3 access levels is for owner, second for group and third for others.
Owner: The user ID of the file owner. Can be checked with the -l option in ls -l.
Group: The group ID of the file owner. Also shown in ls -l.
Size: The size of the file in bytes. Shown in ls -l as the fifth field.
Modified time: When the file was last modified. Shown in ls -l as the sixth and seventh fields.
Access time: When the file was last accessed. This can be viewed with ls -lu.
Inode number: A unique ID for the file. Acts as a file identifier and is used to find the file on the disk. Can be seen using ls -i.
Type: Whether it's a regular file, directory, symlink, device file, socket, pipe etc. Shown using ls -l as the first character.
Device ID: For device files, it shows the device number it corresponds to.
SELinux context: The SELinux security context of the file. Can be viewed using ls -Z.
Extended attributes: Custom attributes that can be assigned to files using the xattr command.
Sticky bit: If the sticky bit is enabled, only the owner or root can delete the file. Shown as
tin ls -l.
These properties give administrators and users a lot of metadata and information about the files and folders on a Linux system. They help manage and organize the file system more effectively.
Example:
Here is an example in bash cli to create groups of users, a new folder and set access for each group. These are linux commands you can type in a terminal:
# Create 3 groups
groupadd devs
groupadd sales
groupadd managers
# Add some users to each group
usermod -a -G devs user1
usermod -a -G devs user2
usermod -a -G sales user3
usermod -a -G sales user4
usermod -a -G managers user5
# Create a new folder
mkdir /data
# Give read/write access to devs group
chmod g+rw /data
chgrp devs /data
# Give read access only to sales group
chmod g+r /data
chgrp sales /data
# Give execute access to managers group
chmod g+x /data
chgrp managers /data
# Deny access to all other users
chmod o-rwx /data
This will:
Create 3 groups: devs, sales and managers
Add some users to each group
Create a /data folder
Give read/write access to the dev's group
Give read-only access to the sales group
Give execute access to the manager's group
Deny access to all other users not in these groups
To really understand what is going on we need to dig deeper. You need to understand the fundamentals of access properties. Continue reading you will find this interesting!
Access Permission
Linux file access permissions are implemented using a bitmask. Each permission - read, write and execute - is represented by a bit in the bitmask. The permissions for the owner, group and others are represented by three sets of three bits.
The bits are assigned as follows:
4 - Read (r)
2 - Write (w)
1 - Execute (e)
So permission like 755 would be represented as:
Owner:
Read - 4 (100 in binary)
Write - 2 (010 in binary)
Execute - 1 (001 in binary)
Total: 4 + 2 + 1 = 7 (111 in binary)
Group:
Read - 4 (100 in binary)
Write - 0 (000 in binary)
Execute - 1 (001 in binary)
Total: 4 + 0 + 1 = 5 (101 in binary)
Others:
- Same as group
So the full bitmask for 755 permission would be:
111 101 101
The chmod command in Linux uses this bitmask to set the file access permissions. It interprets the 3 digit octal number you provide as a bitmask and applies it to the file.
This bitmask representation allows Linux to efficiently store and manipulate file permissions in a compact way, while still providing granular control over the read, write and execute access for owner, group and others.
Default Permissions
There are different kinds of files in Linux, and they require different permissions:
Regular files:
Store data or program code.
Default permissions when created are -rw-rw-r-- (644), meaning readable and writable by owner and group, readable by others.
Directories:
Contain other files and directories.
Default permissions when created are drwxrwxr-x (755), meaning readable, writable and executable by owner and group, readable and executable by others. The executable permission is needed to access files inside the directory.
Executable files:
Programs and scripts.
Default permissions when created are -rwxr-xr-x (755), meaning executable by owner, group and others.
Device files:
Represent devices.
Default permissions are crw-rw---- (660) for character devices, and brw-rw---- (660) for block devices. Only owner has read and write access.
Socket files:
Used for interprocess communication.
Default permissions are srw-rw-rw (666), meaning readable and writable by owner, group and others.
Symbolic links:
Point to other files.
Default permissions are lrwxrwxrwx (777), meaning everyone has read, write and execute permissions.
FIFO files (named pipes):
Used for communication between unrelated processes.
Default permissions are prw-rw-rw (666), meaning readable and writable by owner, group and others.
In summary, different file types require different default permissions based on their purpose and the type of access they need. The permissions are set accordingly when a file is created to ensure appropriate security and functionality.
Hope this explanation of different Linux file types and their default permissions helps! Let me know if you have any other questions.
Copy/Move/Rename
When you copy, move or reorganize files and folders in Linux, the permissions are handled differently depending on the operation:
Copying:
- When you copy a file or folder, the new copy has the same permissions as the original. This is true whether you copy within the same system or to another system.
Moving:
When you move a file within the same system, to a different folder, the permissions remain the same.
But when you move a file to another system, the ownership and permissions may change depending on the user and group settings on the other system. The file's permissions are adjusted to match the defaults for that type of file on the new system.
Renaming:
- When you rename a file or folder, the permissions stay the same. Only the name is changed, the permissions and ownership are unaffected.
So in summary:
Copying preserves permissions
Moving within the same system preserves permissions
Moving to another system may change permissions to match defaults on the new system
Renaming does not affect permissions
The key thing to remember is that when files move across systems, the user and group names may be different on the two systems. So the permissions have to be adjusted to map to the corresponding users and groups on the new system. This may result in the effective permissions changing.
The permissions are really tied to the file itself, independent of its name or location. But when moving across systems, the user/group mappings have to be adjusted, potentially affecting the effective permissions.
Application Specific
Application-specific users and roles are a good security practice in Linux servers to isolate applications and limit the scope of potential damage if an account is compromised.
Some benefits of using application-specific users are:
Limiting privileges: Each application can run under a separate user with only the minimal privileges required for that application. This reduces the attack surface if that account is compromised.
Isolating applications: Each application runs under its own user and cannot access the data of other applications, even if they are on the same server. This provides a degree of multi-tenancy.
Easy monitoring and troubleshooting: Since each application runs under a separate user, you can monitor and troubleshoot that user's activity independently.
Easy to revoke access: If needed, you can disable just that specific user account to revoke access for that application, without affecting other applications.
So instead of all your applications running as the root user or a generic "app" user, you should:
Create a separate user for each application
Assign ownership of that application's files and directories to its specific user
Give that user only the minimal access rights required (using file permissions and groups)
For example, you may have:
A "webapp1" user that runs your first web application
A "webapp2" user for your second web application
A "db" user for your database access
Then if one of the web applications is compromised, only that "webapp1" user is affected - the database and other applications remain secure.
Overall, using application-specific users isolates applications from each other and limits the blast radius of a compromise. Combined with the principle of least privilege, it can significantly improve the security of your Linux servers.
Backup
Here are the steps to back up users and groups for a Linux server:
- Back up the /etc/passwd file. This contains information about all users, including their username, UID, primary group, home directory, and shell.
You can back up this file with:
$ sudo cp /etc/passwd /etc/passwd.bak
- Back up the /etc/shadow file. This contains encrypted passwords for each user.
$ sudo cp /etc/shadow /etc/shadow.bak
- Back up the /etc/group file. This contains information about groups, including the group name, GID, and list of users in the group.
$ sudo cp /etc/group /etc/group.bak
- Back up the /etc/gshadow file. This contains encrypted group passwords.
$ sudo cp /etc/gshadow /etc/gshadow.bak
- Back up user home directories. This preserves all users' data and configurations. You can back up the entire /home directory.
$ sudo tar -czvf /backup/home.tar.gz /home
- Create a timestamped backup. This makes it easier to track different backups over time. You can do something like:
$ sudo tar -czvf /backup/home-$(date +%F).tar.gz /home
- Test your restore process. Occasionally test restoring your backup files to ensure you can successfully recover user and group data when needed.
By following these steps, you have created backups of all the critical files needed to restore your Linux users and groups in the event of data loss or corruption. Storing the backup files on a separate system ensures they will be available even if the main server fails completely.
Disclaim: This article was generated using Rix, an AI tool provided by HashNode. You can write similar articles yourself if you know what to ask. This article was created for my own reasearch. If you find this article useful, please comment below. Thanks!