Chapter 6: Hardening Access Controls
Strong network access controls prevent unauthorized users from accessing a system. File access controls are important not only for preventing intruders from gaining too much access, but also to limit authorized users to their own data, and to maintain secure configuration and log files. This chapter provides an overview of the Linux file system access control capabilities and provides some quick techniques for auditing your system s files and directories to ensure they meet good security practice. Linux distributions have evolved enough that out of the box implies a file system that is already configured with proper restrictions. This means that all configuration files, log files, and programs are owned by the root user and exceptions are made only where necessary. Root ownership of a file or directory is more secure because it limits what other users of the system can access or modify. The trick is to maintain that integrity while adding users, permitting users to add their own files, and installing new applications.
Linux File Permissions and Ownership
If you are comfortable with the Unix file system and understand the concept of users, groups, and access modes, this section may cover many familiar topics, but it s still important to understand the security capabilities of the file system in order to avoid mistakes. This section explains the permission modes and ownership that can be applied to files and directories in the Linux file system. These capabilities and limitations of the file system s permission structure influences the design and implementation of a secure configuration.
Use POSIX Access Control Lists
The standard Linux file system follows the POSIX model of access control. A POSIX (Portable Operating System Interface) standard is intended to establish common behavior among operating system commands. The POSIX access control list (ACL) model did not reach official status as a standard and, in fact, further work on it has been abandoned . Yet it remains the de facto model by which Linux enforces file system security.
Linux files and directories have permission modes and user and group ownership. Valid modes are read ( r ), write ( w ), and execute ( x ). Each of these modes is defined as approved ( true or one of rwx ) or denied ( false or - ). The modes are applied to three categories of users: the mode for the user ID (UID) that owns the file, the mode for the members of the group ID (GID) that owns the file, and the mode for all other users whose UID and GID do not match the file s ownership. Thus, a file s permissions are defined by three groups of three modes as shown in Table 6-1.
| Mode | Alpha Shorthand | Numeric Shorthand |
|---|---|---|
| Read | r | 4 |
| Write | w | 2 |
| Execute (A directory must have execute privileges in order for users to cd into it and search the directory for information such as attributes of files.) | x | 1 |
| Example: Read, Write, Execute | rwz | 7 |
| Example: Read, Write | rw- | 6 |
| Example: Read, Execute | r-x | 5 |
Modes can be combined alphabetically , rwx , or numerically , 7 (4+2+1) . Visually, these settings are clearly discernable with the ls command. The leftmost column of 10 characters indicates the file s permissions (the first character is used to describe the list member as a file, directory, or special device). A file with all permissions would have mode rwxrwxrwx . A file with no permissions would have mode --------- (nine hyphens).
# ls -l /etc/passwd -rw-r--r-- 1 root root 1573 May 6 10:39 /etc/passwd # ls -l /bin/login -rwxr-xr-x 1 root root 20092 Sep 25 2003 /bin/login # ls -l /usr/bin/procmail -rwxr-xr-x 1 root mail 80064 Jan 24 2003 /usr/bin/procmail
The permissions for /etc/passwd are described in Table 6-2.
| Type of User | Mode | Description |
|---|---|---|
| User owns file (UID root) | rw- | Can read, can write, cannot execute |
| Group owns file (GID root) | r-- | Can read, cannot write, cannot execute |
| World (non-user, non-group) | r-- | Can read, cannot write, cannot execute |
The chmod command (change mode) is used to change file access permissions on a file or directory. This command sets and unsets permissions for the user ( u ), group ( g ), world ( o ), or all ( a ). Here is an example that shows how permissions change on a file:
# touch temp.txt # ls -l temp.txt -rw-r--r-- 1 root root 0 Jun 10 14:49 temp.txt # chmod o-r temp.txt # ls -l temp.txt -rw-r-- - -- 1 root root 0 Jun 10 14:49 temp.txt # chmod g+w temp.txt # ls -l temp.txt -rw-r w ---- 1 root root 0 Jun 10 14:49 temp.txt # chmod a-w temp.txt # ls -l temp.txt -r - -r - ---- 1 root root 0 Jun 10 14:49 temp.txt
The chmod command also supports numeric arguments for permissions. Note that this method requires you to set all modes at once: user, group, world.
# touch temp.txt # ls -l temp.txt -rw-r--r-- 1 root root 0 Jun 10 14:53 temp.txt # chmod 0640 temp.txt # ls -l temp.txt -rw-r----- 1 root root 0 Jun 10 14:53 temp.txt # chmod 0660 temp.txt # ls -l temp.txt -rw-rw---- 1 root root 0 Jun 10 14:53 temp.txt # chmod 0440 temp.txt # ls -l temp.txt -r--r----- 1 root root 0 Jun 10 14:53 temp.txt
In this example, a leading zero (0) was added to the three digits used to define the user, group, and world permissions. This leading zero can be omitted. It was included because there is actually a fourth attribute group that is reserved for special permission modes.
Special Permission Modes
The basic modes for all files and directories are read, write, and execute. There are three additional attributes that subtly affect how a file is executed or accessed: set user ID (SUID), set group ID (SGID), and sticky. These attributes work differently when applied to files and directories, as described in Tables 6-3 and 6-4.
| Attribute | Effect When Applied to a File |
|---|---|
| SUID | The file is executed in a process whose privilege matches the UID of the user owner of the file instead of the privilege of the user who executed the file. This is used to enable a user to execute a single program under a different set of privileges. Typically, a file will be SUID root (meaning that it executes with root privileges regardless of the UID of the user) in order to provide a root-level capability to a non-root user. This way users do not have to have a root password and log in to the root account in order to perform a simple task. It is always better to limit the number of persons who have access to the root password for a system. |
| SGID | The file is executed in a process whose privilege matches the GID of the group owner |
| Sticky | None. |
| Attribute | Effect When Applied to a Directory |
|---|---|
| SUID | None. |
| SGID | When a file is created in the SGID directory, the group owner is set to the group owner |
| Sticky | When a file is created in the sticky directory, only the user owner of the file or root can delete or rename the file. This overrides the implied permissions of the directory. For example, if a directory is world-readable and world-writable, then all users would be able to create, delete, and modify files created by any other user. This prevents other users with write permissions to a file from deleting the file. This is most commonly seen on the /tmp directory. |
These modes can be set with the chmod command using numeric arguments. The SUID bit is shown in the place normally reserved for the user s execute permission.
# touch temp.sh # ls -l temp.sh -rw-r--r-- 1 root root 0 Jun 10 17:24 temp.sh # chmod 0755 temp.sh # ls -l temp.sh -rwxr-xr-x 1 root root 0 Jun 10 17:24 temp.sh* # chmod 4755 temp.sh # ls -l temp.sh -rwsr-xr-x 1 root root 0 Jun 10 17:24 temp.sh*
The sticky bit is evident on the system s /tmp directory. The t replaces the execute bit for all other users.
# ls ld /tmp drwxrwxrwt 5 root root 4096 Jun 10 17:24 tmp/
Further information about file permissions, ownership, and modes can be found with the man chmod command.
Implement Extended Attributes
Linux file systems also support extended attributes. The attribute relevant to server hardening is the immutable attribute. When a file is immutable, it cannot be modified, deleted, renamed , or linked to by any user on the system ”including root. It is most useful for protecting sensitive configuration files or other data files whose content is static.
| Caution | The immutable and other attributes depend on support from the kernel s file system driver. The attributes apply to ext2, ext3, ReiserFS file system types, as well as most other file system types available in the stock Linux kernel. If you are running a server that uses a different type of file system, there s a chance you might not have access to these capabilities. This will not be a problem for SUSE, Red Hat, or Mandrake users. Use the mount command to see what type of file system you have if you are unsure. |
For files whose content continually changes, such as log files, the append only attribute can be used to enable the system to continue to write to the file, but not delete, overwrite, or rename the file.
The attributes cannot be viewed or modified with the ls or chmod command. Instead, use the lsattr (list attributes) and chattr (change attributes) commands.
# touch log # chattr +a log # lsattr -----a------- ./log # chattr -a log # lsattr ------------- ./log
It is very important to point out that the root user was able to set and unset these flags. In practice, you will want to restrict even root from removing the append only or immutable attribute. The Linux kernel controls this access via capabilities defined at compile time and accessible via the sysctl interface. The sysctl interface is located in /proc/sys/kernel/cap-bound, but you need a special tool called lcap to easily access this interface.
By default, Red Hat only restricts a single capability that is unrelated to file system management. Use the lcap tool to change capabilities. The tarball (lcap-0.0.3.tar.bz2) is available at http://www.packetstormsecurity.org/. When you restrict access to a capability, the file attributes associated with that capability are recognized, but can no longer be changed. You need to have access to the CAP_LINUX_IMMUTABLE capability in order to set the immutable attribute for a file, but CAP_LINUX_IMMUTABLE is not necessary to enforce the immutable attribute once it has been set.
# ./lcap Current capabilities: 0xFFFFFEFF 0) *CAP_CHOWN 1) *CAP_DAC_OVERRIDE 2) *CAP_DAC_READ_SEARCH 3) *CAP_FOWNER 4) *CAP_FSETID 5) *CAP_KILL 6) *CAP_SETGID 7) *CAP_SETUID 8) CAP_SETPCAP 9) *CAP_LINUX_IMMUTABLE 10) *CAP_NET_BIND_SERVICE 11) *CAP_NET_BROADCAST 12) *CAP_NET_ADMIN 13) *CAP_NET_RAW 14) *CAP_IPC_LOCK 15) *CAP_IPC_OWNER 16) *CAP_SYS_MODULE 17) *CAP_SYS_RAWIO 18) *CAP_SYS_CHROOT 19) *CAP_SYS_PTRACE 20) *CAP_SYS_PACCT 21) *CAP_SYS_ADMIN 22) *CAP_SYS_BOOT 23) *CAP_SYS_NICE 24) *CAP_SYS_RESOURCE 25) *CAP_SYS_TIME 26) *CAP_SYS_TTY_CONFIG * = Capabilities currently allowed
Simply use a capability name as an argument to lcap in order to disable it.
# ./lcap CAP_LINUX_IMMUTABLE # ./lcap Current capabilities: 0xFFFFFCFF 0) *CAP_CHOWN 1) *CAP_DAC_OVERRIDE 2) *CAP_DAC_READ_SEARCH 3) *CAP_FOWNER 4) *CAP_FSETID 5) *CAP_KILL 6) *CAP_SETGID 7) *CAP_SETUID 8) CAP_SETPCAP 9) CAP_LINUX_IMMUTABLE 10) *CAP_NET_BIND_SERVICE 11) *CAP_NET_BROADCAST 12) *CAP_NET_ADMIN 13) *CAP_NET_RAW 14) *CAP_IPC_LOCK 15) *CAP_IPC_OWNER 16) *CAP_SYS_MODULE 17) *CAP_SYS_RAWIO 18) *CAP_SYS_CHROOT 19) *CAP_SYS_PTRACE 20) *CAP_SYS_PACCT 21) *CAP_SYS_ADMIN 22) *CAP_SYS_BOOT 23) *CAP_SYS_NICE 24) *CAP_SYS_RESOURCE 25) *CAP_SYS_TIME 26) *CAP_SYS_TTY_CONFIG * = Capabilities currently allowed
Now the chattr command is prohibited from setting immutable and append flags ( append is assumed with immutable ).
# lsattr ----i-------- log # chattr -i log chattr: Operation not permitted while setting flags on log
The idea is to boot the computer with full capabilities available to users, set the appropriate attributes for the desired files, remove the capabilities, and place the system in a production environment. Now an attacker cannot change an immutable file without gaining root access, rebooting the system, and then modifying the file.
If all other security alarms fail, administrators should at least notice a system reboot.
| Caution | Security measures that attempt ultimate security tend to have exceptions or hacking techniques that the root user can bypass. In the case of securelevel settings, it is possible for an attacker with root privileges to load a kernel module specifically designed to change the capabilities of a running system. Even non-modular kernels can be similarly attacked via manipulation of /dev/mem and /dev/kmem. Securelevel 1 also tries to resolve this by restricting write access to /dev/kmem and preventing modules from being loaded. |
Be very careful when enabling and disabling capabilities on your system. Start with CAP_LINUX_IMMUTABLE and CAP_SYS_RAWIO disabled. This should provide protection for immutable and append only flags that you wish to set.
Linux Standards Base (LSB) Implications
The LSB attempts to create a uniform behavior, naming, and expectations among diverse Linux distributions. Its standards for file system security are simple. New packages to be installed on a system should have these assumptions:
-
Only the user s home, /tmp, /var/tmp, and /var/opt/ package directories are expected to have write permissions even if the package does not own the directory (which it shouldn t). The directories should have the sticky bit set to protect files from only being manipulated by their creator. This limits the amount of world- writeable directories on the system.
-
The package should not expect to have write privileges to any file not owned by the UID or GID of the user executing the process. This means that no files should be world-writeable.
-
The package should not expect to have read or execute access to all files on the system.
-
The package should not expect other files to have SUID or SGID permissions. The package may install a SUID/SGID file, but it should not expect other files not installed by the package to have those permissions. This lets administrators remove SUID/SGID files without breaking dependencies for future packages.
-
The package should not modify the permission modes or ownership of any file not explicitly installed by the package. If it requires permission changes, then it should inform the user.
These are also good guidelines for creating a strong security policy for custom applications or modified applications that will be deployed on your system.
Rely on Samba Tools for Windows File Controls
If your Linux system supports the Samba service, use the Samba tools and administration interfaces to manipulate permissions for files that are shared with Windows computers. The Samba code does an excellent job of mapping Windows access control lists (ACLs) to POSIX ACLs without introducing overhead for the user. Windows ACLs provide more granularity than the basic read/write/execute settings for a user/group/world associated with a file. Samba is able to replicate the philosophy of Windows ACLs while maintaining the actual files on a Samba-shared Linux file system. It does this through extended POSIX ACLs, much like the immutable and append attributes mentioned in the previous section. One of the biggest differences from a file-sharing standpoint is that permissions for a single file can be defined for multiple users. Several users can be assigned different permissions, such as read, write, or delete, while another group of users may be explicitly denied access.
EAN: 2147483647
Pages: 113