Linux Security Mechanisms
In this article, I will give a brief excursion into the most common Linux security tools. The information is provided in a condensed 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 to some extent to security tools, will not be considered, especially since this is a separate, extensive topic.
Description: Differentiation of access rights to files based on their attributes (Discretionary Access Control, DAC).
Mechanism of work: The system (in particular, the file system manager) reads the attributes of the file that the user is accessing (or a program running on behalf of a user) and decides whether to grant access based on these attributes. If an access error occurs, the application returns the corresponding error code.
Usage example: To block / allow other users to access their 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 permissions can be viewed through ls and getfacl .
Additional links : POSIX Access Control Lists on Linux , Advanced ACLs on Linux .
Description: Running programs on your own and / or someone else's name.
Mechanism of work: When the sudo / sudoedit command is called, the system reads the / etc / sudoers file, and on its basis determines what commands the user can invoke.
Usage example: The entire configuration is defined in the / etc / sudoers file. For example, you can only allow certain commands to be executed, and only from a specific user:
This line indicates that users defined in the WEBMASTERS alias can execute all commands on behalf of the www user , or do su only on www .
Description: An operation that restricts a process’s access to the file system by changing 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 (ie the program works in a very conditional "sandbox"). It is not difficult to circumvent this mechanism, especially from under the root, so this tool is not recommended for safety. Only virtualization can provide a real sandbox.
Usage example: A special directory is created, the environment necessary for work is copied to it (you can also use the mount --bind command) Next, chroot is made to this directory, and the running program only works with previously prepared environments. To simplify, you can use the various jail tools available in distributions.
Description: Authentication plugins.
Mechanism of work: Programs written using PAM access its library, which already actually performs the user authentication procedure. If the authorization fails, the corresponding error code is returned to the application.
Usage example: PostgreSQL, Apache, Squid and other programs (including those written by you) can work with user accounts not through their own configuration files, but access PAM, thereby providing various authentication options - Kerberos, eTokens, biometrics, etc. Naturally, this also applies to Linux itself - you can enter not only by driving a couple of username / password.
Description: Implement a Mandatory Access Control (MAC) system based on security policies and contexts.
Mechanism of work: To check access rights, the kernel LSM module is used, which checks the application’s security policy and compares its type with the security context of the files (objects) used. If an access error occurs, the corresponding entry is added to /var/log/audit/audit.log. The user can be notified of this through the setroubleshoot utility .
Usage example: In targeted mode, SELinux allows Apache to read only certain directories. The standard (for someone) way to create a website in the home directory and open it through the symlink in / var / www will not pass the verification procedure, because SELinux checks the file security context by doing a full scan. To change the file security context, use the chcon command(in this case, chcon -R -h -t httpd_sys_content_t / path / to / directory ). Current security contexts can be viewed through ls -Z .
Additional links : Anatomy of SELinux .
Description: Proactive Defense System based on security policies (profiles).
Mechanism of work: To check access rights, the kernel LSM module is used, which, when starting the application, checks for the presence of its profile (/etc/apparmor.d), and if the profile exists, it limits the execution of system calls in accordance with the profile. If an access error occurs, the corresponding entry is added to /var/log/audit/audit.log. The user can be notified about this through the apparmor-notify utility .
Usage example: Using the aa-genprof commandYou can create a profile of an application of interest by fulfilling all the necessary use-cases in it. Further, the resulting profile file can be modified in the way you are interested in, saved in /etc/apparmor.d and activated via aa-enforce .
Description: A tool for controlling system privileges.
The mechanism of work: When the application accesses the service (any call passes as an action), it checks through PolicyKit the user's access rights for this action. Depending on the policies, access may be denied, allowed, or require authentication. The error display (or password request) should be taken over by the client application.
Usage example: when setting up a network, Ubuntu 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 the settings, a password is requested. Moreover, the user is not given root rights to the entire system, because it works only within the limits of 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 features (in Russian), write in the comments. I will also 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 to some extent to security tools, will not be considered, especially since this is a separate, extensive topic.
POSIX ACL
Description: Differentiation of access rights to files based on their attributes (Discretionary Access Control, DAC).
Mechanism of work: The system (in particular, the file system manager) reads the attributes of the file that the user is accessing (or a program running on behalf of a user) and decides whether to grant access based on these attributes. If an access error occurs, the application returns the corresponding error code.
Usage example: To block / allow other users to access their 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 permissions can be viewed through ls and getfacl .
Additional links : POSIX Access Control Lists on Linux , Advanced ACLs on Linux .
sudo
Description: Running programs on your own and / or someone else's name.
Mechanism of work: When the sudo / sudoedit command is called, the system reads the / etc / sudoers file, and on its basis determines what commands the user can invoke.
Usage example: The entire configuration is defined in the / etc / sudoers file. For example, you can only allow certain commands to be executed, 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 www user , or do su only on www .
chroot
Description: An operation that restricts a process’s access to the file system by changing 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 (ie the program works in a very conditional "sandbox"). It is not difficult to circumvent this mechanism, especially from under the root, so this tool is not recommended for safety. Only virtualization can provide a real sandbox.
Usage example: A special directory is created, the environment necessary for work is copied to it (you can also use the mount --bind command) Next, chroot is made to this directory, and the running program only works with previously prepared environments. To simplify, you can use the various jail tools available in distributions.
PAM
Description: Authentication plugins.
Mechanism of work: Programs written using PAM access its library, which already actually performs the user authentication procedure. If the authorization fails, the corresponding error code is returned to the application.
Usage example: PostgreSQL, Apache, Squid and other programs (including those written by you) can work with user accounts not through their own configuration files, but access PAM, thereby providing various authentication options - Kerberos, eTokens, biometrics, etc. Naturally, this also applies to Linux itself - you can enter not only by driving a couple of username / password.
SELinux
Description: Implement a Mandatory Access Control (MAC) system based on security policies and contexts.
Control is called forced when the control is applied by administrators and the system, and does not depend on the decision of users, as is the case with conventional access control. [ * ]
Mechanism of work: To check access rights, the kernel LSM module is used, which checks the application’s security policy and compares its type with the security context of the files (objects) used. If an access error occurs, the corresponding entry is added to /var/log/audit/audit.log. The user can be notified of this through the setroubleshoot utility .
Usage example: In targeted mode, SELinux allows Apache to read only certain directories. The standard (for someone) way to create a website in the home directory and open it through the symlink in / var / www will not pass the verification procedure, because SELinux checks the file security context by doing a full scan. To change the file security context, use the chcon command(in this case, chcon -R -h -t httpd_sys_content_t / path / to / directory ). Current security contexts can be viewed through ls -Z .
Additional links : Anatomy of SELinux .
Apparmor
Description: Proactive Defense System based on security policies (profiles).
Mechanism of work: To check access rights, the kernel LSM module is used, which, when starting the application, checks for the presence of its profile (/etc/apparmor.d), and if the profile exists, it limits the execution of system calls in accordance with the profile. If an access error occurs, the corresponding entry is added to /var/log/audit/audit.log. The user can be notified about this through the apparmor-notify utility .
Usage example: Using the aa-genprof commandYou can create a profile of an application of interest by fulfilling all the necessary use-cases in it. Further, the resulting profile file can be modified in the way you are interested in, saved in /etc/apparmor.d and activated via aa-enforce .
Policykit
Description: A tool for controlling system privileges.
The mechanism of work: When the application accesses the service (any call passes as an action), it checks through PolicyKit the user's access rights for this action. Depending on the policies, access may be denied, allowed, or require authentication. The error display (or password request) should be taken over by the client application.
Usage example: when setting up a network, Ubuntu 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 the settings, a password is requested. Moreover, the user is not given root rights to the entire system, because it works only within the limits of 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 features (in Russian), write in the comments. I will also be glad to all the comments and inaccuracies found.