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