Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
ContentsContents
Security and Hardening Guide
Navigation
Applies to SUSE Linux Enterprise Server 15 SP2

13 File Management Edit source

13.1 Disk Partitions Edit source

Servers should have separate file systems for at least /, /boot, /usr, /var, /tmp, and /home. This prevents, for example, that logging space and temporary space under /var and /tmp fill up the root partition. Third-party applications should be on separate file systems as well, for example under /opt.

Another advantage of separate file systems is the possibility to choose special mount options that are only suitable for certain regions in the file system hierarchy. A number of interesting mount options are:

  • noexec: prevents execution of files.

  • nodev: prevents character or block special devices from being usable.

  • nosuid: prevents the set-user-ID or set-group-ID bits from being effective.

  • ro: mounts the file system read-only.

Each of these options needs to be carefully considered before applying it to a partition mount. Applications may stop working, or the support status may be violated. When applied correctly, mount options can help against some types of security attacks or misconfigurations. For example, there should be no need for set-user-ID binaries to be placed in /tmp.

You are advised to review Chapter 2, Common Criteria. It is important to understand the need to separate the partitions that could impact a running system (for example, log files filling up /var/log are a good reason to separate /var from the / partition). Another thing to keep in mind is that you will likely need to leverage LVM or another volume manager or at the very least the extended partition type to work around the limit of four primary partitions on PC class systems.

Another capability in SUSE Linux Enterprise Server is encrypting a partition or even a single directory or file as a container. Refer to Chapter 14, Encrypting Partitions and Files for details.

13.2 Checking File Permissions and Ownership Edit source

The following sections deal with some ways the default permissions and file settings can be modified to enhance the security of a host. It is important to note that the use of the default SUSE Linux Enterprise Server utilities like seccheck - can be run to lock down and improve the general file security and user environment. However, it is beneficial to understand how to modify these things.

SUSE Linux Enterprise Server hosts include three default settings for file permissions: permissions.easy, permissions.secure, and permissions.paranoid, all located in the /etc directory. The purpose of these files is to define special permissions, such as world-writable directories or, for files, the setuser ID bit (programs with the setuser ID bit set do not run with the permissions of the user that has launched it, but with the permissions of the file owner, usually root).

Administrators can use the file /etc/permissions.local to add their own settings. The easiest way to implement one of the default permission rule-sets above is to use the Local Security module in YaST.

Each of the following topics will be modified by a selected rule-set, but the information is important to understand on its own.

13.3 Default umask Edit source

The umask (user file-creation mode mask) command is a shell built-in command that determines the default file permissions for newly created files and directories. This can be overwritten by system calls but many programs and utilities use umask.

By default, umask is set to 022. This umask is subtracted from the access mode 777 if at least one bit is set.

To determine the active umask, use the umask command:

tux > umask
022

With the default umask, you see the behavior most users expect to see on a Linux system.

tux > touch a
tux > mkdir b
tux > ls -on
total 16
-rw-r--r--. 1 17086    0 Nov 29 15:05 a
drwxr-xr-x. 2 17086 4096 Nov 29 15:05 b

You can specify arbitrary umask values, depending on your needs.

tux > umask 111
tux > touch c
tux > mkdir d
tux > ls -on
total 16
-rw-rw-rw-. 1 17086    0 Nov 29 15:05 c
drw-rw-rw-. 2 17086 4096 Nov 29 15:05 d

Based on your threat model, you can use a stricter umask such as 037 to prevent accidental data leakage.

tux > umask 037
tux > touch e
tux > mkdir f
tux > ls -on
total 16
-rw-r-----. 1 17086    0 Nov 29 15:06 e
drwxr-----. 2 17086 4096 Nov 29 15:06 f
Tip
Tip: Maximum Security

For maximum security, use a umask of 077. This will force newly created files and directories to be created with no permissions for the group and other users.

Please note that this can be unexpected for users and software and might cause additional load for your support team.

13.3.1 Adjusting the Default umask Edit source

You can modify the umask globally for all users by changing the UMASK value in /etc/login.defs.

# Default initial "umask" value used by login(1) on non-PAM enabled systems.
# Default "umask" value for pam_umask(8) on PAM enabled systems.
# UMASK is also used by useradd(8) and newusers(8) to set the mode for new
# home directories.
# 022 is the default value, but 027, or even 077, could be considered
# for increased privacy. There is no One True Answer here: each sysadmin
# must make up their mind.
UMASK           022

For indivudual users, add the umask to the 'gecos' field in /etc/password like this:

tux:x:1000:100:Tux Linux,UMASK=022:/home/tux:/bin/bash

You can do the same with yast users by adding UMASK=022 to a user's Details › Additional User Information.

The settings made in /etc/login.defs and /etc/password are applied by the PAM module pam_umask.so. For additional configuration options, refer to man pam_umask.

In order for the changes to take effect, users need to log out and back in again. Afterwards, use the umask command to verify the umask is set correctly.

13.4 SUID/SGID Files Edit source

When the SUID (set user ID) or SGID (set group ID) bits are set on an executable, it executes with the UID or GID of the owner of the executable rather than that of the person executing it. This means that, for example, all executables that have the SUID bit set and are owned by root are executed with the UID of root. A good example is the passwd command that allows ordinary users to update the password field in the /etc/shadow file which is owned by root.

But SUID/SGID bits can be misused when the executable has a security hole. Therefore, you should search the entire system for SUID/SGID executables and document it. To search the entire system for SUID or SGID files, you can run the following command:

root # find /bin /boot /etc /home /lib /lib64 /opt /root /sbin /srv /tmp /usr /var -type f -perm '/6000' -ls

You might need to extend the list of directories that are searched if you have a different file system structure.

SUSE only sets the SUID/SGID bit on binary if it is really necessary. Ensure that code developers do not set SUID/SGID bits on their programs if it is not an absolute requirement. Very often you can use workarounds like removing the executable bit for world/others. However, a better approach is to change the design of the software or use capabilities.

SUSE Linux Enterprise Server supports file capabilities to allow more fine grained privileges to be given to programs rather than the full power of root:

root # getcap -v /usr/bin/ping
      /usr/bin/ping = cap_new_raw+eip

The previous command only grants the CAP_NET_RAW capability to whoever executes ping. In case of vulnerabilities inside ping, an attacker can gain at most this capability in contrast with full root. Whenever possible, file capabilities should be chosen in favor of the SUID bit. But this only applies when the binary is suid to root, not to other users such as news, lp and similar.

13.5 World-Writable Files Edit source

World-writable files are a security risk since they can be modified by any user on the system. Additionally, world-writable directories allow anyone to add or delete files. To locate world-writable files and directories, you can use the following command:

root # find /bin /boot /etc /home /lib /lib64 /opt /root /sbin /srv /tmp /usr /var -type f -perm -2 ! -type l -ls

You might need to extend the list of directories that are searched if you have a different file system structure.

The ! -type l parameter skips all symbolic links since symbolic links are always world-writable. However, this is not a problem as long as the target of the link is not world-writable, which is checked by the above find command.

World-writable directories with the sticky bit such as the /tmp directory do not allow anyone except the owner of a file to delete or rename it in this directory. The sticky bit makes files stick to the user who created it and it prevents other users from deleting and renaming the files. Therefore, depending on the purpose of the directory, world-writable directories with sticky are usually not an issue. An example is the /tmp directory:

tux > ls -ld /tmp
drwxrwxrwt 18 root root 16384 Dec 23 22:20 /tmp

The t mode bit in the output denotes the sticky bit.

13.6 Orphaned or Unowned Files Edit source

Files not owned by any user or group might not necessarily be a security problem in itself. However, unowned files could pose a security problem in the future. For example, if a new user is created and the new users happens to get the same UID as the unowned files have, then this new user will automatically become the owner of these files.

To locate files not owned by any user or group, use the following command:

root # find /bin /boot /etc /home /lib /lib64 /opt /root /sbin /srv /tmp /usr /var -nouser -o -nogroup

You might need to extend the list of directories that are searched if you have a different file system structure.

A different problem is files that were not installed via the packaging system and therefore don't receive updates. You can check for such files with the following command:

tux > find /bin /lib /lib64 /usr -path /usr/local -prune -o -type f -a -exec /bin/sh -c "rpm -qf {} &> /dev/null || echo {}" \;

Run this command as an untrusted user (for example nobody) since crafted file names might lead to command execution. This shouldn't be a problem since these directories should only be writeable by root, but it's still a good security precaution.

This will show you all files under /bin, /lib, /lib64 and /usr (with the exception of files in /usr/local) that are not tracked by the package manager. These files might not represent a security issue, but you should be aware of what is not tracked and take the necessary precautions to keep these files up to date.

Print this page