11:34 Security mechanisms in linux | |
| In this article, I will spend a short excursion to the most common means of security-related Linux. Information is provided in a compressed form, and unless some means you are interested, you can follow the link and read in more detail. Upon request of users, some mechanisms can be considered in greater detail in subsequent articles. Will consider the following tools: POSIX ACL, sudo, chroot, PAM, SELinux, AppArmor, PolicyKit. Virtualization, although concerns to some extent to the means of security will not be considered, especially because it is a separate large topic. POSIX ACLDescription: access rights to files based on their attributes (Discretionary Access Control, DAC). The mechanism works: system (in particular, the manager of the filesystem) reads the attributes of a file accessed by the user (or a program running on behalf of any user), and decides whether to grant access based on these attributes . On error, access application returns an appropriate error code. Example: To disable / enable access to other users to their files, you can change its attributes through the chmod, and change owner / group through the chown and chgrp (or use a more general command setfacl). Current access rights can be viewed via ls and getfacl. links: POSIX Access Control Lists on Linux, Advanced ACL in Linux. SudoDescription: Running programs on their own and / or someone else's name. The mechanism works: When you call the command sudo / sudoedit system reads the file / etc / sudoers, and based on that determines what commands can cause the user. Example: All configuration is defined in the file / etc / sudoers. For example, you can allow to perform only certain commands, and only from a specific user: WEBMASTERS www = (www) ALL, (root) / usr / bin / su www This line says that users are identified in an alias WEBMASTERS can perform all the commands from the www, or do su only www. chrootDescription: The operation, which limits access of the file system, changing its root in the context of the process. The mechanism works: starts the program (default / bin / sh) to the context in which redefined the root file system. Now all calls caused by the program can not go beyond the root directory (ie, the program works in a very conditional "sandbox"). Circumvent this mechanism is not difficult, especially as root, so that the tool is not recommended for safety. This sandbox can only provide virtualization. Example: a special directory, it copies required for the work environment (you can also use the mount - bind). Next is chroot to that directory and running the program works only with pre-prepared environment. To simplify, you can use a variety of jail-tools available in Linux distributions. PAMDescription: Pluggable Authentication Modules. The mechanism works: Programs written using PAM, turning to his library, which already holds itself to authenticate the user. On error, the authorization application returns an appropriate error code. Example: PostgreSQL, Apache, Squid and other programs (including written by you) can work with user accounts not through your own configuration files, refer to the PAM, thereby providing various options for authentication - Kerberos, eTokens, biometrics, etc. Naturally, this applies to most Linux-well - you can include not only driving a couple of login / password. SELinuxDescription: Implementation of Mandatory Access Control (Mandatory Access Control, MAC), based on policies and security contexts. Control called positive when the application is made by administrators and control system, and does not depend on the decisions of users, as is the usual access control. [*] The mechanism works: To check the access rights using LSM-kernel module, which checks the security policy application, and compares his style with the security context used files (objects). On error, access a corresponding entry is added to the / var / log / audit / audit.log. The user can get notification about it through the utility setroubleshoot. Example: In the targeted-mode SELinux allow Apache to read only certain directories. Standard (for someone) the way to make a website in your home directory and open it via a symlink in / var / www does not pass the vetting process because SELinux checks the security context of files, doing a full scan. To change the security context file, you must use the chcon (in this case, chcon-R-h-t httpd_sys_content_t / path / to / directory). The current security context can be viewed through the ls-Z. links: Anatomy of SELinux. AppArmorDescription: System proactive protection based on security policies (profiles). The mechanism works: To check the access rights using LSM-kernel module, which is when the application starts it checks the profile (/ etc / apparmor.d), and if the profile exists, it limits the performance of the system calls in accordance with the profile. On error, access a corresponding entry is added to the / var / log / audit / audit.log. The user can get notification about it through the utility apparmor-notify. Example: With the command aa-genprof You can create a profile of interest to the application, having worked in it all appropriate use-case-s. Next, the file can modify the profile of interest to you, keep in / etc / apparmor.d and activate a aa-enforce. PolicyKitDescription: tool control system privileges. The mechanism works: When accessing the application to the service (any treatment takes place as the action), it checks through PolicyKit user permissions for this action-as well. Depending on access policies can be prohibited, permitted or require authentication. Mapping error (or request a password) must be on yourself to take a client application. Example: Ubuntu to configure the network can view all information without requiring a password (because PolicyKit configuration allows reading without authorization), but when it is necessary to save the settings, it asks for a password. Moreover, the user is not given rutovskie law on the entire system, because it only works within the service used. ConclusionsOf course, there are other means of security-related, not discussed in this article. However, all of the above is the de facto standard for most common distributions, and if you care about safety, it is desirable to know them. If anyone has more relevant links to the description of the security (in Russian), write a comment. Will also be welcome to all the comments and found inaccuracies. | |
|
| |
| Total comments: 0 | |