LPI E C1 - secure procs

System Account Security

Understanding the Inner Workings of Linux System Accounts, Memory Management, and Access Control Lists (ACLs)

Assessment Test: https://www.certificationmethods.com/2023/05/lpi-e-ic-sys-acct-test.html

If you've ever used Linux, you're probably familiar with system accounts, memory management, and access control lists (ACLs). These are essential components of any modern operating system, and Linux is no exception. In this blog post, we'll take a closer look at these concepts and explain how they work together to keep your Linux system secure. 

Let's start with system accounts

Every Linux system has a set of default system accounts that are created during installation. These accounts are stored in files such as "/etc/passwd", "/etc/group", and "/etc/shadow". These files contain information about each account, including the username, password (encrypted), group membership, and home directory. The system accounts are used to run various system processes and services, and they have different levels of access to the system resources.

The Linux kernel provides mechanisms to manage system accounts, including process isolation, resource allocation, and memory protection. These mechanisms ensure that each account has its own memory space and cannot access the memory of other accounts. They also prevent system accounts from accessing restricted resources and executing unauthorized commands.

Memory management is another crucial aspect of Linux

It involves managing the memory resources of the system and allocating them to different processes and applications. The Linux kernel provides various memory management mechanisms, including segmentation, memory mapping, and virtual memory. These mechanisms ensure that each process has its own memory space and cannot access the memory of other processes. They also provide protection against buffer overflow attacks and other memory-related vulnerabilities.

Access control lists (ACLs) are used to manage access to files and directories on the Linux system

They provide a way to define granular permissions for users and groups, allowing administrators to control who can read, write, and execute files. The Linux kernel provides support for ACLs through the Extended File Attributes (Xattrs) system. This system allows administrators to set and modify ACLs for files and directories using tools such as "setfacl" and "getfacl".  (CLI EXAMPLES BELOW)

By understanding how system accounts, memory management, and ACLs work in Linux, you can ensure that your system is secure and well-managed. If you're preparing for a Linux certification exam or just want to test your knowledge, we've prepared a sample practice exam that covers these topics and more. You can find the practice exam at the end of this blog post.

"etc/passwd" "etc/shadow" "etc/group"

The files /etc/passwd, /etc/shadow, and /etc/group are important system files used by the Linux operating system to manage user accounts and group membership.

• /etc/passwd: This file contains basic information about user accounts, such as the username, user ID (UID), home directory, and default shell. By default, most Linux systems create several system accounts with predefined user IDs, including root (UID 0), daemon (UID 1), bin (UID 2), sys (UID 3), adm (UID 4), and so on.
• /etc/shadow: This file stores encrypted password information for user accounts. Only the root user and certain system processes can read this file. By default, the root account is the only user with access to this file.
• /etc/group: This file contains information about user groups, such as the group name and group ID (GID). By default, most Linux systems create several system groups with predefined GIDs, including root (GID 0), bin (GID 1), daemon (GID 2), sys (GID 3), adm (GID 4), and so on.

25 Common default system accounts 

👏😲

1. root: This is the superuser account with full administrative privileges. It is typically used for system administration tasks and has UID 0.
2. daemon: This account is used by system processes that run in the background, such as the print spooler or web server. It has UID 1.
3. bin: This account is used to own system binaries that are essential for the operation of the system. It has UID 2.
4. sys: This account is used to own system files and directories that are essential for the operation of the system. It has UID 3.
5. adm: This account is used to manage system logs and is typically used for auditing purposes. It has UID 4.
6. nobody: This account is used by some system services and daemons to run with restricted privileges, usually for security reasons. It has UID -2 and GID -2.
7. systemd-journal: This account is used by the systemd-journald daemon, which is responsible for system logging. It has UID 190 and GID 190.
8. systemd-network: This account is used by the systemd-networkd daemon, which is responsible for network configuration. It has UID 192 and GID 192.
9. systemd-resolve: This account is used by the systemd-resolved daemon, which is responsible for DNS resolution. It has UID 193 and GID 193.
10. messagebus: This account is used by the D-Bus system message bus, which allows communication between processes. It has UID 999 and GID 998.
11. lp: This account is used by the print spooler system, which manages print jobs. It has UID 7 and GID 7.
12. mail: This account is used by the mail system, which manages email. It has UID 8 and GID 12.
13. news: This account is used by the Usenet news system, which manages news articles. It has UID 9 and GID 13.
14. uucp: This account is used by the Unix-to-Unix Copy (UUCP) system, which allows file transfers between systems. It has UID 10 and GID 14.
15. proxy: This account is used by some proxy servers to run with restricted privileges. It has UID 13 and GID 13.
16. www-data: This account is used by the Apache web server to run with restricted privileges. It has UID 33 and GID 33.
17. ftp: This account is used by the FTP server to manage file transfers. It has UID 14 and GID 50.
18. sshd: This account is used by the OpenSSH server, which provides encrypted remote access to the system. It has UID 74 and GID 74.
19. games: This account is used by some games and game servers to run with restricted privileges. It has UID 60 and GID 60.
20. dbus: This account is used by the D-Bus system message bus, which allows communication between processes. It has UID 81 and GID 81.
21. mysql: This account is used by the MySQL database server. It has UID 109 and GID 109.
22. postgres: This account is used by the PostgreSQL database server. It has UID 26 and GID 26.
23. apache: This account is used by the Apache web server. It has UID 48 and GID 48.
24. tomcat: This account is used by the Apache Tomcat application server. It has UID 91 and GID 91.
25. nagios: This account is used by the Nagios monitoring system. It has UID 110 and GID 117.

The underlying service that allows these accounts in the /etc/passwd file access is the Linux kernel

When a user logs into a Linux system, the login process checks the username and password in the /etc/passwd and /etc/shadow files, respectively. If the login is successful, a new shell process is created for the user, with the user's UID and GID values set as the effective user and group IDs for the process.

The Linux kernel then uses these effective user and group IDs to determine what level of access the user has to the system resources. Each file and directory on the system has an associated set of permission bits that determine which users and groups are allowed to access the file and in what way. The kernel checks the user's effective UID and GID against these permission bits to determine whether the user is allowed to access a given file or directory.

In short, the Linux kernel uses the user and group information in the /etc/passwd file to enforce access control and security policies throughout the system.

Processes and services managing accounts, in addition to the Linux kernel and the /etc/passwd file

One of these processes is the Pluggable Authentication Modules (PAM) framework, which provides a standardized way to manage user authentication across different Linux distributions and applications. PAM allows for flexible authentication policies, including support for multiple authentication methods such as passwords, smart cards, and biometric devices.

Another service that may be involved is the Name Service Switch (NSS) system, which provides a way for Linux systems to access user and group information from various sources, such as LDAP directories, NIS servers, and other systems on the network. NSS allows for centralized user management and authentication across multiple systems, making it easier to manage large-scale deployments.

Many Linux distributions implement security features such as SELinux (Security-Enhanced Linux) or AppArmor, which provide additional access control policies and help to prevent unauthorized access to system processes and resources. These security features can be configured to restrict users to certain types of activities and prevent them from executing certain types of commands or accessing certain files or directories.

While there may be several processes and services involved in managing user accounts on a Linux system, the Linux kernel remains the core component that enforces access control policies and keeps users from accessing system processes not allowed for them. 

Kernel Mechanisms

The Linux kernel provides a wide range of mechanisms for controlling access to system resources and ensuring the security of the system.

While service accounts are subject to the same access control policies as regular users, additional mechanisms such as 

• IPC limits
• prctl() system call
• Namespaces
• Linux Security Modules (LSM) to control access and isolate service accounts from each other or from starting other system accounts
• Access Control Lists (ACLs) to control access to system processes and resources
  
• Capabilities can be used to further isolate service accounts and prevent unauthorized access to critical system processes and resources
• Auditing - 
• the auditd daemon
• the tripwire utility
  

The Linux kernel provides mechanisms to limit or control inter-process communication (IPC) between processes. For example, the prctl() system call can be used to set specific limits on the ability of a process to interact with other processes, such as limiting the types of IPC mechanisms that can be used or setting restrictions on the use of shared memory.

The Linux kernel provides namespaces, which allow for the creation of isolated environments within a Linux system. Namespaces provide a way to partition system resources such as network interfaces, file systems, and process IDs, allowing for the creation of independent environments for different service accounts or applications.

Another mechanism that can be used to control access between service accounts is the Linux Security Modules (LSM) framework. LSM provides a way to add additional security policies to the Linux kernel, such as SELinux or AppArmor, which can be used to limit the access of service accounts to each other or to system resources.

Linux also uses file permissions and access control lists (ACLs) to control access to system processes and resources. Each file in Linux has a set of permissions that determine who can read, write, or execute the file. These permissions are enforced by the kernel, and they apply to both regular users and service accounts.

The etc/passwd file, for example, is typically only readable by the root user, while the etc/shadow file is only readable by the root user and members of the shadow group. This ensures that only authorized users and service accounts can access sensitive user account information.

ACL's in greater detail below

👇🤓👍

Another way that Linux controls access to system processes is through capabilities. Capabilities are a set of privileges that can be granted to individual processes or programs, allowing them to perform specific privileged operations that would normally require root-level access. For example, a process may be granted the CAP_NET_ADMIN capability, which allows it to configure network interfaces, without requiring root-level access.

Linux also provides tools for auditing system activity and tracking changes to critical system files. For example, the auditd daemon can be used to track system calls and file accesses, while the tripwire utility can be used to monitor changes to critical system files and alert system administrators when changes are detected.

Kernel Mechanisms:
Elevated Privilege Shared Memory Security

In Linux, each process is isolated from other processes in terms of its memory space. This means that each process has its own virtual memory space that is separate from the virtual memory spaces of other processes. This isolation ensures that one process cannot access the memory of another process directly.

To protect the memory of each account from other system accounts that have elevated privileges to the core system, Linux uses a combination of access control mechanisms and memory protection mechanisms.

Access control mechanisms such as file permissions and ACLs are used to control access to shared memory segments and memory-mapped files. By default, these mechanisms ensure that only authorized users and service accounts can access shared memory segments or memory-mapped files.

Linux also uses memory protection mechanisms such as shared memory segmentation and memory mapping to protect the memory of each process from other processes that allow processes to share memory in a controlled manner. 

Memory segmentation divides the virtual memory space of each process into multiple segments, each with its own set of access permissions. Memory mapping allows a process to map a portion of a file or shared memory segment into its virtual memory space, providing direct access to the mapped memory region while protecting the rest of the process's memory from other processes.

The x86 architecture, which is commonly used in desktop and server systems, provides support for memory segmentation through the use of memory segment registers. These registers are used to specify the base address and size of each memory segment, as well as the access permissions for the segment. The CPU enforces these access permissions by checking them against the segment registers each time a memory access is made.

Linux provides hardware-level memory protection features such as Memory Protection Keys (MPKs) on x86 processors, which allow processes to set up memory regions that can only be accessed by specific code paths.

Memory mapping, on the other hand, allows a process to map a portion of a file or shared memory segment into its virtual memory space. The mapped memory region can be accessed directly by the process as if it were part of its own memory space. This allows processes to share data between each other efficiently without requiring the overhead of copying data between processes.

EXAMPLE:
A service account that needs to share a data structure with another system account process may create a shared memory segment using the shmget system call. The service account can then attach to the shared memory segment using the shmat system call, which maps the shared memory segment into the service account's virtual memory space. The service account can then read from or write to the shared memory segment as needed, while other system account processes are prevented from accessing the shared memory segment directly.

Overall, the combination of access control mechanisms, memory protection mechanisms, and hardware-level memory protection features ensures that each account's memory is protected from other system accounts that have elevated privileges to the core system. This helps to maintain the security and integrity of the system by preventing unauthorized access or modification of critical system memory.

Kernel Mechanisms:
Access Control Lists (ACL)

Access Control Lists (ACLs) are a feature of the Linux kernel that allow for more fine-grained control over file and directory permissions beyond the standard UNIX permissions. ACLs allow users and system accounts to specify permissions for multiple users and groups on a file or directory.

ACLs are created and managed using the setfacl and getfacl commands, which are part of the acl package. These commands allow users and system accounts to view and modify the ACLs of files and directories.

The syntax for creating an ACL using setfacl is as follows:

$ setfacl -m user:username:permissions file

Here, user specifies the type of object that the ACL applies to (in this case, a user), username specifies the name of the user, permissions specifies the permissions to be granted to the user, and file specifies the file or directory that the ACL applies to.

For example, to grant read, write, and execute permissions to the user "john" on the file "example.txt", the following command can be used:

$ setfacl -m user:john:rwx example.txt

To view the ACL of a file or directory, the getfacl command can be used:

$ getfacl file

This will display the ACL entries for the specified file or directory.

The Linux kernel uses ACLs to enforce access control on files and directories. When a file or directory is accessed, the kernel checks the permissions specified in the ACL for the user and group that is accessing the file or directory. If the user or group has the necessary permissions specified in the ACL, then access is granted. If not, access is denied. 

ACLs are stored in the extended attribute namespace of the file system, which allows for additional metadata to be associated with files and directories beyond the standard UNIX metadata. The kernel uses this extended attribute namespace to store and manage the ACLs of files and directories.

In summary, ACLs are created and managed using the setfacl and getfacl commands, and are enforced by the Linux kernel when a file or directory is accessed. ACLs are stored in the extended attribute namespace of the file system, which allows for more fine-grained control over file and directory permissions.

Summary:

When a Linux system boots, the first thing that happens is the system firmware is loaded and initialized. The firmware then loads the bootloader, which is responsible for loading the kernel and initializing the system hardware. Once the kernel is loaded, it initializes the memory management subsystem and sets up the initial process, known as the init process.

Here are the key steps involved in the boot process and subsequent execution of service accounts, along with details on how ACLs and memory management are used to maintain security:

1. Bootloader: The bootloader is the first program that runs when a Linux system is started. It loads the kernel and initializes the hardware.
2. Kernel: The kernel is the core of the Linux operating system. It manages system resources such as memory, CPU, and input/output (I/O) devices. It also creates and manages service accounts, which are stored in the "etc/passwd" file. 
3. Service Accounts: Service accounts are used to run various system services and applications. They are created by the kernel and stored in the "etc/passwd" file. Each service account has a unique user ID (UID) and group ID (GID). These IDs are used to control access to system resources.
4. Access Control Lists (ACLs): ACLs are used to manage access to files, directories, and other system resources. They are created and managed by the kernel and stored in the "etc/group" file. Each ACL specifies which users and groups are allowed to access a particular resource.
5. Memory Management: Memory management is used to allocate, protect, and manage system memory. Each service account has its own memory space, which is protected from other service accounts by the kernel. Memory mapping and segmentation are used to allocate and manage memory.
6. Shadow Passwords: To further enhance security, Linux uses shadow passwords to store encrypted passwords for each user. The encrypted passwords are stored in the "etc/shadow" file, which is only accessible by the root user.
7. Service Startup: Once the kernel has created service accounts and initialized memory management and ACLs, it begins to start up system services and applications. Each service is started using its associated service account, which has been granted access to the necessary system resources. 

Definitions

Kernel initialization and memory management:

• During kernel initialization, the memory management subsystem is initialized, which includes setting up the memory protection mechanisms, segmentation and memory mapping processes.
• The kernel also initializes the security subsystem, which is responsible for enforcing security policies on the system.

init process and service account initialization:

• The init process is the first process that is started by the kernel and is responsible for starting all other processes, including service accounts.
• When a service account is initialized, it is assigned a unique process ID (PID) and a range of memory addresses that it can access. These memory addresses are protected by the memory protection mechanisms provided by the kernel.

Access Control Lists (ACLs):

• ACLs are used to enforce access control on files and directories. When a file or directory is accessed, the kernel checks the permissions specified in the ACL for the user and group that is accessing the file or directory.
• ACLs are stored in the extended attribute namespace of the file system, which allows for additional metadata to be associated with files and directories beyond the standard UNIX metadata.
• ACLs are created and managed using the setfacl and getfacl commands, which allow users and system accounts to view and modify the ACLs of files and directories.

Service account permissions and access control:

• Service accounts are assigned permissions based on the ACLs associated with the files and directories they are allowed to access.
• The kernel enforces these permissions by checking the ACLs associated with a file or directory before granting access to a service account.
• Service accounts are also restricted from accessing memory outside of their assigned range of memory addresses, which helps prevent them from accessing system processes not allowed for them.

Inter-service account communication and memory protection:

• Service accounts can communicate with each other through inter-process communication mechanisms, such as pipes, sockets, and shared memory segments.
• When using shared memory segments, the kernel ensures that each service account can only access its own memory segment and cannot access the memory segments of other service accounts.
• This is accomplished through the use of memory protection mechanisms, such as segmentation and memory mapping, which ensure that each service account has its own protected area of memory to work with.

In conclusion, the Linux operating system is designed to be secure and robust. Service accounts, ACLs, and memory management are all critical components of Linux security. The kernel plays a key role in creating and managing these components, ensuring that each service account is isolated and protected from other service accounts. By following best practices for service account management and ACLs, Linux administrators can help to ensure that their systems are secure and protected from unauthorized access.