Secure filesystem mount points, an fstab howto.

Posted by Jason Sat, 14 Oct 2006 16:22:00 GMT

Howto make your system more secure through smart fstab configuration

When, in the unfortunate event, that an intruder has gained access to you system, it is wise to limit what he can do with the files available to him in the areas of the filesystem that he has been able to access.  One way to add a level of difficulty to the attacker escalating the level of compromise is through secure mount points.

When the file system is brought online, it passes flags called mount points to the operating system kernel's code which govern how that filesystem may be accessed.  With careful planning you can engineer mount point options to prevent files from being interpreted as device nodes, disallow binaries from being executed, or to disallow the SUID bit from taking affect from taking advantage of the 'nodev', 'noexec' and 'nosuid' flags, or even forcing the filesystem to be mounted read-only using the 'ro' option.  These options can be specified as switches to the mount command in combination with the '-o' flag.  For example, if you have a separate partition for /store that is on the forth partition of your first scsi disk, you can mount this partition using these flags in the following manner

# mount -o nodev,noexec,nosid /dev/sda4 /store

If you wanted this configuration to load from fstab instead, the entry would look something like this (with slight variations across different flavors of linux / unix)

/dev/sda4   /store   ext3   defaults,nodev,noexec,nosid   1   2

It is worth taking time to consider the requirements while partitioning your disks into multiple filesystems, as a properly planned fstab configuration can make it harder for an attacker to further compromise your system.  Some considerations while dividing up your storage are whether or not the partition needs write access to function.  Filesystems that do not need to be changed often could be mounted as read only, such as /usr.  Normally, the /usr partition is not written to unless system updates are being made.  Depending on your software configurations you may wish to have this partition mounted read-only by default, and then remount it as writable before performing system updates.

Many directories will need to be mounted as writable for the system to function properly.  Most user directories on a multiuser system are placed in /home.  Although users will obviously want to be able to write to their home directories, most admins will most likely not wanting these users to have the ability to execute SUID binaries or create device files within their home directory.  A security minded admin may wish to have a separate /home partition only for user accounts, and have this partition mounted using the 'nodev' and 'nosuid' options.  To make things more secure, an admin could recommend a security policy that disallows users to execute programs stored in their home directories using the 'noexec' option. 

A common policy for securing a system can also be seen in blocking off /var and /tmp as separate partitions.  Normal operations in these partitions generally do not require that permission be granted to any process to access device files or execute SUID or non-SUID binaries.  This can be a big help in reducing the impact that an attacker can have since it will not allow malicious programs to run.  The attacker may be able to install, say Trojan software in /tmp or in a users home directory, but without the proper chmod commands given by the superuser the malware will not be able to run.

There are certain circumstances where intelligently crafting an fstab file will help suppress the escalation of an attack, and certain times where it will not.  If for instance the attacker has managed to obtain root access, be can remount the filesystem with any options he wishes.  Another, less obvious one, is a weakness found in linux, and more specifically dynamically linked libraries.  For example, a skilled cracker will be aware of the fact that in linux the 'noexec' option can be bypassed by directly calling ld-linux.so to execute binaries residing on filesystems that are using this mount option.  There is a catch twenty-two here, because the only way to effectively squash this is to make the ld-linux.so library non-executable which would leave a system with all dynamically linked libraries non-executable.  Since few of the libraries in a modern distribution of linux are statically linked, in most situations the 'noexec' has little to no affect for a skilled attacker in linux. 

Mount points are not a way to prevent an attack.  To be honest, even the best fstab configuration will still provide little defense against a skilled attack.  It is in no way a complete security policy which would prevent attacks or add a great level of protection.  What correctly mounting filesystems can provide is a way to drastically limit the options that an attacker has in the event of system compromise.

Interesting ha?  Hope it helps..


Composed by Jason K. Jackson


This site completely supported by Google advertising



Posted in  | Tags , , , , ,  | no comments

Comments

(leave url/email »)

   Preview comment