Title: File system considerations in Linux

KBTAG: kben10000036
URL: http://www.securityportal.com/lskb/10000000/kben10000036.html
Date created: 15/04/2000
Date modified: 24/08/2000
Date removed:
Authors(s): Kurt Seifried seifried@securityportal.com
Topic: Setting up your filesystems in Linux with security in mind
Keywords: Filesystem, System/Install

Implementation information:
Difficulty: mild
Requirements: fresh install (moving file systems around within Linux is tricky)
Time (approx.): 10 minutes
Comments: doing this at the start can save you grief later

Summary:

Linux, like most UNIX systems uses a directory structure based off of /, which directories like /home, /tmp, /usr, and so on. These directories can be placed on the same partition, or separate partitions, separating them properly can have security (and performance) benefits. There are also a number of mounting options that can be used to prevent common problems and attacks.

More information:

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 is typically defended against by assigning root a set percentage of the disk space as reserve (usually 5-10%), so on a 10 gig disk users would not be able to use the last 500 megs, this would be reserved for root. This doesn't do you any good however if something running as root, that generates log files, goes nuts, or is attacked and made to generate massive log files. 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:

Some notes on the various flags

noexec, if you mount /tmo noexec for example you can copy a binary in, but it will not run, however if you execute it using ld-linux.so it will work fine:

[seifried@stench /tmp]$ ./date 
bash: ./date: Permission denied
[seifried@stench /tmp]$ /lib/ld-linux.so.2 ./date 
Thu Aug 24 21:59:08 MDT 2000
[seifried@stench /tmp]$ 

 

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 trojan's, 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 trojan's, 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 /vat/ 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.