Tip of the Day: mount options
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
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.:
A sample, -but you can always change it to suit your needs- fstab file could be like:
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
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
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.
A sample, -but you can always change it to suit your needs- fstab file could be like:
/dev/sd0a / ffs rw 1 1For 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).
/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
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
Keywords: ToD
0 comment(s)
×
Diary Archives
Comments