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:

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 openSUSE Leap is encrypting a partition or even a single directory or file as a container. Refer to Chapter 14, Encrypting Partitions and Files for details.

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 openSUSE Leap 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.

openSUSE Leap 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.

The umask (user file-creation mode mask) command is a shell built-in command which 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. You can modify this globally by changing the value in /etc/profile or for each user in the startup files of the shell.

To determine the active umask, use the umask command:

tux > umask
022

The umask is subtracted from the access mode 777 if at least one bit is set.

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 thread model you can use a stricter umask like 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

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.

openSUSE Leap 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.

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.

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.