No operating system is 100% secure. The only perfectly secure computer is one that's been disconnected from all power and locked in a safe with an armed guard [1]. Unfortunately, computers are not terribly useful in that configuration.

Realistic security strikes a balance between mitigation of risks and necessary functionality. While most Linux distributions are, in the default configuration, more secure than many alternative OSes, there are still things that can be done to improve the default security.

This paper focuses on tasks that can improve the security of SUSE Linux Enterprise Server v10 (SLES10). There are a number of similar references available on the Internet [2]; this paper presents specific suggestions derived from a number of sources, including the author's own experience.

Implementation of any secure environment begins long before actually installing the OS. In particular, it's important to consider the intended purpose of the server. For example, the security issues inherent in a webserver are somewhat different from those of a server hosting shared filesystems.

The purpose of the server also determines what packages are appropriate to install, and offers some input in the partitioning of disk space. For example, a server intended simply to provide file sharing services probably doesn't need a compiler installed on it, and a webserver probably has little need for a Samba installation.

Before installing SLES10, you should review the packages that are part of the distribution. If you don't recognize a package, or don't understand its function, research it. When you identify packages that will not be necessary for the role the server will play, eliminate them - either deselect them during the installation process, or go back afterward and remove them.

Other critical decisions, such as to use (or not use) an X11 GUI (for example, KDE or GNOME), and access methods/services (e.g. SSH, VNC), should be made before starting an install. The fewer access methods supported, the fewer access methods that might be exploited to gain entry to or elevate access on a host. Insecure X11 listeners are particularly problematic.

Finally, consider creating a Patch CD [3] to enable patching your new SLES10 host prior to actually connecting it to a network. While it might seem overly paranoid to worry about the time-window necessary for on-line update, patching off-line offers inexpensive insurance against threats to unpatched systems.

Disk partitioning can play a role in maintaining a secure environment. There are as many recommendations of the "proper" way to partition your disks, and what filesystems to choose, as there are Linux administrators. While the needs of your specific environment may cause you to select one approach over another, there are still defensive tactics that are appropriate to practically every environment.

For example, consider a system that will be used to host a directory structure shared with other systems using, say, NFS as a transport. Perhaps these are user "home" directories, so let's say that the directories will be placed within the /home directory structure.

In such a scenario, system security can be enhanced by placing the /home directory structure in its own filesystem partition. Doing so enables useful flags to be added to the mount entry in /etc/fstab, such as nosuid, nodev and noexec. These flags would help thwart exploits that rely on slipping an suid-flagged executable, or a bogus device, in through an NFS "backdoor". These flags generally make sense for most disk space writable by nominally-unprivileged users with shell access. The noexec flag would be appropriate if you want to generally prevent users with local shell access from running executables they upload or create.

There is a little-discussed caution about the mount flags recommended above - they are not an absolute protection. They raise the bar for the attacker, and in particular are useful against canned attacks made without local shell access. However, in Linux specifically, the linker and loader both can be used to circumvent the noexec flag, and this can be leveraged by users with local shell access. It is also possible to run things like Perl scripts located on a partition mounted noexec. Another example of a local attack to sidestep a mount flag involves using the -r flag with the umount command to sidestep the nosuid flag (CVE-2005-2876 [4]; for which there is a SUSE patch [5]).

In many environments, separating /var into its own partition, also mounted with those flags, can be an effective measure. Such a move would limit opportunities for unauthorized privilege escalation attempts that leverage legitimate world-writable directories, like /var/tmp. Additionally, DoS attacks that attempt to fill up the system logs in /var/log would be limited to affecting a single partition, and not be able to deny disk space to other critical directory structures, like /usr.

Along these same lines, consider mounting /tmp as it's own partition, and for many of the same reasons. There are a number of exploits that rely on the ability of unprivileged users to write files to /tmp, and then leverage other vulnerabilities (for example, a cron vulnerability like CVE-2006-2607 [6]) to escalate privilege. It may be possible to replace /tmp with a link to /var/tmp, as this can thwart similar exploits that depend on how /tmp appears in the kernel's filesystem structures.

A less-common recommendation is to create /boot as a separate partition. One obvious advantage to doing so is to mount (in /etc/fstab) this partition as read-only, thus preventing casual alteration of the kernel binaries, and removing a rarely-examined location from the list of places where malware might be easily hidden. Depending on your BC/DR procedures, splitting /boot into its own partition may make system recovery easier. The downside to a read-only mount is that deploying legitimate kernel and GRUB patches will take extra steps.

Even less common is a tip to mount /proc and /dev/shm using both noexec and nosuid. These are "special" filesystems and there is no sane reason for either executable files, or set-SUID bits, to be found in either filesystem.

In summary, when considering disk layout and filesystem selection [7], base your decisions on what makes the most sense for your environment, and the purpose of the SLES host. There are security advantages to be had by splitting selected filesystems out from under the root filesystem, and making judicious use of mount flags to restrict functionality when appropriate.

© 2007 David Bank