SANS ISC: Tip of the Day: mount options

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

Well today might be the day of the 12 Microsoft patches, but to balance that out a little bit, we'll do a unix minded tip of the day.

John wrote in a few days ago and suggested using mount options on different filesystems to tell the operating system not to allow certain kinds of operations or files to be used in that filesystem.

To use options that allow for

• noexec: do not allow executables
• nosuid: do not allow suid executable
• nodev: do not allow devices
  
• rdonly: do not allow writing to this filesystem
  

you need to create sufficient slices to start with.

This can lead to some tries before you get their size right, but once you can a separate / , /usr, /tmp, /home, /var, ... you can set different options to prevent certain uses of certain filesystems. The trick to get the sizes right is to oversize them deliberately and keep a few 2Gbyte sized spare slices around. After a few years, or even months you'll love the space and flexibility in shuffling things around as they need to be without so much as a reboot.

The tricky part that remains is to find which options you cannot use where, e.g.:

• the filesystem containing /dev (usally /) needs to allow devices.
• the filesystems containing /bin and /usr/bin need to allow executables and most likely suid programs as well.
  
• read-only mounting has great advantages, but make sure you can still patch the files and then downgrade the rights again before taking such a system in production.
  

While on the subject, it's smart to create a partition for the target of a chroot jail.  You might need to allow some devices inside the chroot environment's /dev. It's also harder to break out of the hail if the new root is also the root of filesystem.

A sample, -but you can always change it to suit your needs- fstab file could be like:

/dev/sd0a / ffs rw 1 1
/dev/sd0b /tmp mfs rw,nodev,nosuid,noexec,-s=153600 0 0
/dev/sd0d /usr/src ffs rw,nodev,nosuid,softdep 1 2
/dev/sd0e /var ffs rw,nodev,nosuid,softdep 1 2
/dev/sd0f /home ffs rw,nodev,nosuid,softdep 1 2
/dev/cd0a /cdrom cd9660 ro,noauto 0 0
/dev/sd1a /data1 ffs rw,nodev,nosuid,noexec,softdep 1 2
/dev/sd1b none swap sw 0 0
/dev/sd1d /data2 ffs rw,nodev,nosuid,noexec,softdep 1 2

For those wondering, this comes from an OpenBSD fileserver. Attentive readers might note a mountpoint revceiving far less protection. That's because I consider this server to be physicaslly rather safe and don't use the cdrom drive at all. Manual pages to check on your system would include mount(8) and fstab(5).


Our next Tip of the Day will be about patching, how do/did you handle the patches coming out from Microsoft today (or how do you handle those form Mozilla, Sun, Oracle, Linux, ...). Let us know your best practices and Mike Poor will summarize them into a tip tomorrow.
Remember, the Tip of the Day is about sharing positive experiences in order to outsmart the bad guys.

--
Swa Frantzen -- Section 66