Linux security mechanisms
In this article, I will give a brief insight into the most common tools related to Linux security. The information is provided in a compressed form, and if any tool interests you, you can follow the links and read in more detail. At the request of users, some mechanisms can be considered in more detail in subsequent articles.
The following tools will be considered: POSIX ACL, sudo, chroot, PAM, SELinux, AppArmor, PolicyKit. Virtualization, although it relates in some measure to security tools, will not be considered, especially since this is a separate, broad topic.
Description: Differentiate access rights to files based on their attributes (Discretionary Access Control, DAC).
Mechanism of operation: The system (in particular, the file system manager) reads the attributes of the file accessed by the user (or the program running on behalf of a user), and decides whether to grant access based on these attributes. If an access error occurs, the corresponding error code is returned to the application.
Example of use: To prohibit / allow access of other users to your file, you can change its attributes via chmod , and change the owner / group via chown and chgrp (or use the more general setfacl command). Current access rights can be viewed via ls and getfacl .
Additional links : POSIX Access Control Lists on Linux , Extended ACLs for Linux .
Description: Run programs on your and / or someone else's name.
Mechanism of operation: When you invoke the sudo / sudoedit command, the system reads the / etc / sudoers file, and based on it determines which commands the user can invoke.
Example use: The entire configuration is defined in the / etc / sudoers file. For example, you can allow to execute only certain commands and only from a specific user:
This line indicates that users defined in the WEBMASTERS alias can execute all commands on behalf of the user www , or do su only in www .
')
Description: An operation that limits the process access to the file system, modifying its root in the context of the process.
Mechanism of operation: Runs the program (by default / bin / sh) with a context in which the root directory of the file system is redefined. Now, all calls of the called program cannot go beyond the root directory (i.e., the program works in a very conditional sandbox). Bypassing this mechanism is not difficult, especially from under the root, so this tool is not recommended for safety. This sandbox can only provide virtualization.
Example of use: A special directory is created, the environment required for operation is copied into it (you can also use the mount --bind command ). Further chroot on this directory becomes, and the started program works only with previously prepared environment. For simplicity, you can use the various jail-tools that are available in distributions.
Description: Plug-in authentication modules.
Mechanism of work: Programs written using PAM refer to its library, which is actually conducting the user authentication procedure. If authorization fails, an appropriate error code is returned to the application.
Example of use: PostgreSQL, Apache, Squid and other programs (including those written by you) can work with user accounts not through their own configuration files, but refer to PAM, thereby providing various authentication options — Kerberos, eTokens, biometrics, etc. This also applies to Linux itself - you can log in not only by typing a login / password pair.
Description: An implementation of a Mandatory Access Control (MAC) system based on security policies and contexts.
Mechanism of operation: The LSM module of the kernel is used to verify the access rights, which are checked by the application's security policy and compared with the security context of the used files (objects). In case of access error, the corresponding entry is added to /var/log/audit/audit.log. The user can receive notification of this through the utility setroubleshoot .
Usage example: In the targeted mode, SELinux allows an Apache to read only certain directories. The standard (for someone) way to make a website in your home directory and open it through the symlink in / var / www will not pass the verification procedure, since SELinux checks the security context of files by doing a full scan. To change the security context of a file, you must use the chcon command (in this case, chcon -R -h -t httpd_sys_content_t / path / to / directory ). Current security contexts can be viewed via ls -Z .
Additional links : SELinux Anatomy .
Description: A proactive protection system based on security policies (profiles).
Mechanism of work: The LSM kernel module is used to verify the access rights, which, when the application starts, checks the presence of its profile (/etc/apparmor.d), and if the profile exists, it restricts the execution of system calls in accordance with the profile. In case of access error, the corresponding entry is added to /var/log/audit/audit.log. The user can receive notification of this through the utility apparmor-notify .
Example of use: Using the aa-genprof command, you can create a profile of the application of interest, having completed all the necessary use-cases in it. Next, the resulting profile file can be modified in the way that interests you, saved to /etc/apparmor.d and activated via aa-enforce .
Description: A system privilege control tool.
Mechanism of work: When an application accesses a service (any appeal passes as an action), it checks through the PolicyKit the user's access rights for the given action. Depending on the policies, access may be denied, allowed or require authentication. Displaying errors (or asking for a password) should be taken by the client application.
Example of use: Ubuntu when setting up a network allows you to view all information without asking for a password (because the PolicyKit configuration allows reading without authorization), but when you need to save settings, you are prompted for a password. Moreover, the user is not given root rights to the entire system, since It works only within the service used.
Naturally, there are other security-related tools not covered in this article. However, all of the above is the de facto standard for the most common distributions, and if you care about security, it is advisable to know them.
If someone has more relevant links to the description of security tools (in Russian), write in the comment. Also I will be glad to all the comments and inaccuracies found.
The following tools will be considered: POSIX ACL, sudo, chroot, PAM, SELinux, AppArmor, PolicyKit. Virtualization, although it relates in some measure to security tools, will not be considered, especially since this is a separate, broad topic.
POSIX ACL
Description: Differentiate access rights to files based on their attributes (Discretionary Access Control, DAC).
Mechanism of operation: The system (in particular, the file system manager) reads the attributes of the file accessed by the user (or the program running on behalf of a user), and decides whether to grant access based on these attributes. If an access error occurs, the corresponding error code is returned to the application.
Example of use: To prohibit / allow access of other users to your file, you can change its attributes via chmod , and change the owner / group via chown and chgrp (or use the more general setfacl command). Current access rights can be viewed via ls and getfacl .
Additional links : POSIX Access Control Lists on Linux , Extended ACLs for Linux .
sudo
Description: Run programs on your and / or someone else's name.
Mechanism of operation: When you invoke the sudo / sudoedit command, the system reads the / etc / sudoers file, and based on it determines which commands the user can invoke.
Example use: The entire configuration is defined in the / etc / sudoers file. For example, you can allow to execute only certain commands and only from a specific user:
WEBMASTERS www = (www) ALL, (root) /usr/bin/su wwwThis line indicates that users defined in the WEBMASTERS alias can execute all commands on behalf of the user www , or do su only in www .
')
chroot
Description: An operation that limits the process access to the file system, modifying its root in the context of the process.
Mechanism of operation: Runs the program (by default / bin / sh) with a context in which the root directory of the file system is redefined. Now, all calls of the called program cannot go beyond the root directory (i.e., the program works in a very conditional sandbox). Bypassing this mechanism is not difficult, especially from under the root, so this tool is not recommended for safety. This sandbox can only provide virtualization.
Example of use: A special directory is created, the environment required for operation is copied into it (you can also use the mount --bind command ). Further chroot on this directory becomes, and the started program works only with previously prepared environment. For simplicity, you can use the various jail-tools that are available in distributions.
Pam
Description: Plug-in authentication modules.
Mechanism of work: Programs written using PAM refer to its library, which is actually conducting the user authentication procedure. If authorization fails, an appropriate error code is returned to the application.
Example of use: PostgreSQL, Apache, Squid and other programs (including those written by you) can work with user accounts not through their own configuration files, but refer to PAM, thereby providing various authentication options — Kerberos, eTokens, biometrics, etc. This also applies to Linux itself - you can log in not only by typing a login / password pair.
SELinux
Description: An implementation of a Mandatory Access Control (MAC) system based on security policies and contexts.
Control is called compulsory when control is applied by administrators and the system, and does not depend on the decision of users, as it happens with normal access control. [ * ]
Mechanism of operation: The LSM module of the kernel is used to verify the access rights, which are checked by the application's security policy and compared with the security context of the used files (objects). In case of access error, the corresponding entry is added to /var/log/audit/audit.log. The user can receive notification of this through the utility setroubleshoot .
Usage example: In the targeted mode, SELinux allows an Apache to read only certain directories. The standard (for someone) way to make a website in your home directory and open it through the symlink in / var / www will not pass the verification procedure, since SELinux checks the security context of files by doing a full scan. To change the security context of a file, you must use the chcon command (in this case, chcon -R -h -t httpd_sys_content_t / path / to / directory ). Current security contexts can be viewed via ls -Z .
Additional links : SELinux Anatomy .
AppArmor
Description: A proactive protection system based on security policies (profiles).
Mechanism of work: The LSM kernel module is used to verify the access rights, which, when the application starts, checks the presence of its profile (/etc/apparmor.d), and if the profile exists, it restricts the execution of system calls in accordance with the profile. In case of access error, the corresponding entry is added to /var/log/audit/audit.log. The user can receive notification of this through the utility apparmor-notify .
Example of use: Using the aa-genprof command, you can create a profile of the application of interest, having completed all the necessary use-cases in it. Next, the resulting profile file can be modified in the way that interests you, saved to /etc/apparmor.d and activated via aa-enforce .
PolicyKit
Description: A system privilege control tool.
Mechanism of work: When an application accesses a service (any appeal passes as an action), it checks through the PolicyKit the user's access rights for the given action. Depending on the policies, access may be denied, allowed or require authentication. Displaying errors (or asking for a password) should be taken by the client application.
Example of use: Ubuntu when setting up a network allows you to view all information without asking for a password (because the PolicyKit configuration allows reading without authorization), but when you need to save settings, you are prompted for a password. Moreover, the user is not given root rights to the entire system, since It works only within the service used.
Conclusion
Naturally, there are other security-related tools not covered in this article. However, all of the above is the de facto standard for the most common distributions, and if you care about security, it is advisable to know them.
If someone has more relevant links to the description of security tools (in Russian), write in the comment. Also I will be glad to all the comments and inaccuracies found.
Source: https://habr.com/ru/post/92239/
All Articles