Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Protective partitioning

There are a number of common attacks/exploits in Linux (and UNIX) that can be reduced in risk and significance with a proper directory and partition structure.

One of the most common denial of service attacks is to fill up the disk space with junk data, this can also happen unintentionally with software that experiences a problem. This doesn't do you any good however if someone can force a legitimate application to generates massive amount of log files and feel the /var subsystem

The next big attack that takes advantage of disk setup would be /tmp races, and core dumps, programs that create links or files improperly without checking to make sure they exist first, especially programs that run as root. An attacker can then link /tmp/foo to /etc/passwd and potentially add a user account, wipe the password database out, and so on.

Mounting options can be used to mount a partition read only, not allow execution of programs, and other useful things. You may encounter difficulties when using these options however, for example if you mount /usr as read only you will have significantly more work when upgrading system components, especially on critical servers (such as e-commerce machines) that need to be up and running, but also require critical updates. More useful options are "nosuid" (no setuid or setgid files), "noexec" (no executables) and "nodev" (no device files).

So with this in mind we have several guidelines:

• Put filesystems that users can write to on separate partitions
• Put filesystems with critical system components/configuration on separate partitions
• Consider mounting some partitions with system binaries as read-only (this will make upgrades more difficult however), mounting /bin/, /sbin/ and /etc/ separately however will make booting the system tricky (depending on your configuration), test this before using it in a production environment.

Example of RHEL5 protective partitioning

The idea is to minimize privileges via mount options. Among typical measure we can mention( Hardening Red Hat Enterprise Linux 5):

• Noexec on everything possible
• Nodev everywhere except / and chroot partitions
• Nosuid everywhere except /
• Consider making /var/tmp link to /tmp, or maybe mount –bind option

A example of "priviledge minimized"  /etc/fstab:

LABEL=/              /              ext3 defaults                           1 1

LABEL=/tmp           /tmp           ext3 defaults,nosuid,noexec,nodev       1 2

LABEL=/var/log/audit /var/log/audit ext3 defaults,nosuid,noexec,nodev       1 2

LABEL=/home          /home          ext3 defaults,nosuid,nodev              1 2

LABEL=/var           /var           ext3 defaults,nosuid                    1 2

LABEL=/boot          /boot          ext3 defaults,nosuid,noexec,nodev       1 2

/tmp                 /var/tmp       ext3 defaults,bind,nosuid,noexec,nodev  1 2

tmpfs                /dev/shm       tmpfs defaults                          0 0

devpts               /dev/pts       devpts gid=5,mode=620                   0 0

sysfs                /sys           sysfs defaults                          0 0

proc                 /proc          proc defaults                           0 0

LABEL=SWAP-sda6      swap           swap defaults                           0 0

Old News

Securing Linux, Part 3 Hardening the system

Securing local filesystems
Securing the local filesystem deals with ownership of files and directories and access rights to them. To secure the filesystem, the protection bits of files and directories must set to grant minimum access only.

Take special care with respect to inappropriate permissions regarding world-writable files and system directories and so-called setuid or setgid commands. These commands are executed with higher user privileges than the user running the command actually has. This might be necessary to access files that only root has access to (such as /bin/passwd needs to access /etc/passwd). For each of these commands, make sure that it really needs the setuid/setgid bits set. If this is not the case, disable it.

When all files on a partition definitely do not need the setuid/setgid bits, the nosuid option in /etc/fstab disables it for each file on the corresponding filesystem (/dev/hdc1 in the following example):

#device mountpoint filesystemtype options dump fsckorder /dev/hda1 / ext2 defaults 1 1 ... /dev/hdc1 /mnt/cdrom iso9660 nosuid,user 1 2

Furthermore, for very sensitive data, it might make sense to encrypt that data and protect it with a passphrase. GnuPG provides a suitable package to accomplish this.

Some notes on the various flags

Questionable recommendations. should be taken with the grain of salt.

Dir.	nodev	noexec	nosuid	read-only	separate	comments
/	yes	yes	yes	yes	good idea	Ideally you should mount / totally restricted and then have directories like /boot/ separate, this also forces you to configure the directories properly since any "dangerous" directory (for example /dev/) will be "broken" (i.e. nodev would severely break /dev/). This is only recommended if you are going all out.
/boot/	yes	yes	yes	ok	good idea	Critical directory with kernel images, if an attacker replaces your kernel or deletes it you have a lot of problems.
/bin/	yes	no	no	ok	tricky	Directory with important system binaries, do not mount noexec or nosuid, your system will not work correctly. Mounting read-only will prevent trojans, and make updating software significantly more difficult.
/dev/	no	yes	yes	no	yes	Mounting /dev/ with the nodev option will severely break your system, as will mounting it read only. /dev/ is usually less then a few megs, and the ability to write to device files can result in huge damage, and system compromise.
/etc/	yes	yes	yes	no	tricky	Critical directory with system configuration information, usually the first target for an attacker. There should be no binaries in here (although some Unix systems do keep binaries in /etc/, Linux is not one of them). Mounting it read only will not allow you to change passwords, or other important settings so is not recommended.
/home/	yes	good idea	yes	no	yes	/home/ is the primary area where users keep their files and work with them (assuming they can log in), if you provide services like IMAP this is where their mail folders will be. You should make it a separate partition since users have a tendency of eating up space rapidly, as well it will prevent them from making hard links to files and then using setuid programs that dump core for example and wiping out system files. Mounting it noexec is probably a good idea, however depending on the type of work users do it may seriously hamper them, mounting it nosuid is a good idea and shouldn't really affect users.
/lib/	yes	no	yes	ok	good idea	Most programs will rely on libraries in this directory, if they are damaged or compromised you will have a hard time cleaning up. There are executable files in here (.so's, etc.), so setting it noexec would not be advised, but setting it nosuid is probably wise.
/mnt/	yes	good idea	good idea	ok	no need	/mnt/ is typically used to mount removable devices, such as /mnt/floppy/ or /mnt/cdrom, as such it rarely contains anything other then a few directories, making it separate is not a real issue since anything in it will be mounted as well.
/opt/	yes	no	no	no	good idea	Typically this directory is used for optional packages, vendor software and the like, oftentimes this stuff needs setuid bits to work properly (a good reason to separate it since a lot of vendors have terrible software security).
/proc/						/proc/ is a virtual filesystem
/root/	yes	no	no	no	good idea	root's private playground usually, many people use it instead of /usr/local/ when testing things/etc
/sbin/	yes	no	no	ok	tricky	Directory with other important system binaries, do not mount noexec or nosuid or you will break your system. Mounting read-only will prevent trojans, and make updating software significantly more difficult.
/tmp/	yes	yes	yes	no	yes	Temporary directory for use by users and system, mount read only will break things, make it separate because many exploits consist of making hard links in tmp to files, and then having a program misbehave and destroy/modify the target file maliciously. Binaries, especially setuid binaries should not be allowed in /tmp/ since any user can modify them usually.
/usr/	yes	no	no	ok	good idea	This directory is where the majority of software will be installed, along with source code and other stuff typically, mounting it separately is a good idea since it tends to contain relatively important software (especially in /usr/bin and /usr/sbin). Mounting it read only will prevent an attacker from inserting trojan software, but will make upgrades significantly harder. I wouldn't bother mounting it read only unless you also mount /bin/ and /sbin/ read only.
/var/	yes	yes	yes	no	yes	/var/ is used for a lot of things, least of which includes system logging. This partition should be separate since attackers can attempt to fill it up by flooding the log files, and other user data is stored here, such as mail (/var/spool/mail usually). Software that stores data here includes: Mail servers (Sendmail, Postfix, etc.), INN (Usenet news), Proxy software like Squid (WWW/FTP proxy), and so on. There should be no binaries at all here, just log files and data. Setting it noexec may break programs, Red Hat 7.0 places various binaries used for anonymous ftp with WuFTPD and arpwatch binaries in /var/ for example. You can place those files on another partition and symlink the directories to within /var/.

Recommended Links

Hardening Red Hat Enterprise Linux 5