Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / SUSE Linux Enterprise Server Documentation / Security and Hardening Guide / Local Security / File Management
Applies to SUSE Linux Enterprise Server 15 SP2

11 File Management

11.1 Disk Partitions

Servers should have separate file systems for at least /, /boot, /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 26, 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 12, Encrypting Partitions and Files for details.

11.2 Modifying permissions of certain system files

Many files—especially in the /etc directory—are world-readable, which means that unprivileged users can read their contents. Normally this is not a problem, but if you want to take extra care, you can remove the world-readable or group-readable bits for sensitive files.

SUSE Linux Enterprise provides the permissions package to easily apply file permissions. The package comes with three pre-defined system profiles:

easy

Profile for systems that require user-friendly graphical user interaction. This is the default profile.

secure

Profile for server systems without fully-fledged graphical user interfaces.

paranoid

Profile for maximum security. In addition to the secure profile, it removes all special permissions like setuid/setgid and capability bits.

Warning
Warning: Unusable system for non-privileged users

Except for simple tasks like changing passwords, a system without special permissions might be unusable for non-privileged users.

Do not use the paranoid profile is as-is, but as a template for custom permissions. More information can be found in the permissions.paranoid file.

To define custom file permissions, edit /etc/permissions.local or create a drop-in file in the /etc/permissions.d/ directory.

# Additional custom hardening
   /etc/security/access.conf       root:root       0400
   /etc/sysctl.conf                root:root       0400
   /root/                          root:root       0700

The first column specifies the file name; note that directory names must end with a slash. The second column specifies the owner and group, and the third column specifies the mode. For more information about the configuration file format, refer to man permissions.

Select the profile in /etc/sysconfig/security. To use the easy profile and custom permissions from /etc/permissions.local, set:

PERMISSION_SECURITY="easy local"

To apply the setting, run chkstat --system --set.

The permissions will also be applied during package updates via zypper. You could also call chkstat regularly via cron or a systemd timer.

Important
Important: Custom file permissions

While the system profiles are well tested, custom permissions can break standard applications. SUSE cannot provide support for such scenarios.

Always test custom file permissions before applying them with chkstat to make sure everything works as desired.

11.3 Changing Home Directory Permissions from 755 to 700

By default, home directories of users are accessible (read, execute) by all by users on the system. As this is a potential information leak, home directories should only be accessible by their owners.

The following commands will set the permissions to 700 (directory only accessible for the owner) for all existing home directories in /home:

> sudo chmod 755 /home
> sudo bash -c 'for dir in /home/*; do \
echo "Changing permissions of directory $dir"; chmod 700 "$dir"; done'
Important
Important: Test permission changes

Users are no longer allowed to access other users' home directories. This may be unexpected for users and software.

Test this change before using it in production and notify users affected by the change.

11.4 Default umask

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:

> umask
022

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

> touch a
> mkdir b
> 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.

> umask 111
> touch c
> mkdir d
> 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.

> umask 037
> touch e
> mkdir f
> 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.

11.4.1 Adjusting the Default umask

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 individual users, add the umask to the 'gecos' field in /etc/passwd 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/passwd 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.

11.5 SUID/SGID Files

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:

# 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:

# 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.

11.6 World-Writable Files

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:

# 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:

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

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

11.7 Orphaned or Unowned Files

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:

# 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:

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