I came across the following filesystem hierarchy standard however am unsure how I should partition the directories if I am using the logical volume manager and if I wish to secure or harden the installation as much as possible.

enter image description here

I am aware it depends on what I plan to use the PC/server for however would like to know what is generally recommended as a base installation e.g. keep /var, /var/log, /var/spool because they change constantly.

Secondly how much space is required for the /boot and /root directory assuming if I were to segment directories such as /home, /usr,/var, etcetera as their own mount points?

If I only have the /boot mount point outside the logical volumes, does it provide me with sufficient security? What does it not provide me security against?

  • I honestly do not see how partition schemes impact security in any way. – user1686 Aug 31 '11 at 21:43
  • @grawity - My understanding is that partition schemes allow for granular control. – PeanutsMonkey Aug 31 '11 at 22:05
  • 2
    Studying security, I can't see how a multi-partition scheme would improve security. If an attacker has any interface to your partition scheme then they already have too much access. Access controls are your application/operating system/filesystem's jobs, not your partition table. The attack surface won't change substantially depending on partition scheme, they'll still be mounted to the same places. – jcrawfordor Aug 31 '11 at 22:45
  • 1
    I think you may be misunderstanding your basic readings. Partitioning schemes don't affect your security against an attack ("hack"), however you may have read about "securing" your system against rogue processes filling up your hard drive and bringing the system down. For example, if /home is on a separate partition, a user trying to dump in their entire 700TB movie collection would fill up /home, but being on a separate partition it wouldn't hurt the processes that rely on writing to e.g. /tmp to function. So you're "secure" against certain disk space issues with complex partitioning schemes. – Kromey Aug 31 '11 at 23:04
  • 1
    Kromey is correct, partitioning can be a useful tool to control your disk usage, along with OS-enforced quotas. I don't see how denial of service attacks apply, though... even if we get really imaginative and pretend that someone is conducting a DoS attack against your hard disk (and if they are, the box has long ago been pwned), the bottleneck is in the disk controller, and it will fail under the same load regardless of the number of partitions under it. Partitions don't give you more devices, they just split up the device in its logical presentation. – jcrawfordor Aug 31 '11 at 23:10

Let me provide some contrast to the comments on the question.

If you examine the graphic in some detail, there are some security options that become open with proper partitioning. Some quick examples:

  • Anything that is marked static or read-only can be mounted ro (read-only).
  • Anything that isn't /dev can be mounted nodev (no device files will be honored).
  • Any partition that doesn't require setuid binaries can be mounted nosuid (the setuid bit and setgid bits are ignored).
  • Temporary partitions can be mounted or handled in such a way that data on them cannot persist beyond a reboot (e.g. creating a new encrypted file system at each boot with a random key thrown away after mount)
  • For some partitions, you could mount them remotely and read-only from an NFS server. This is a trick that was popular on Solaris.

You can probably come up with some more sophisticated combinations or approaches with some work by examining the options to mount. Another one that looks useful is noexec, for example.

These changes won't mean perfect security. They can make various attacks significantly more challenging to implement. As an example it is harder to drop a trojaned setuid binary on a partition that is mounted nosuid and ro.

In short, partitioning can provide some security benefits. It won't be perfect security, but it can make an attacker's job more difficult.

| improve this answer | |
  • Thanks. I am relatively new to the world of Linux so am unaware of setuid and setgid bits but hope to cover them in my Linux journeys. I do however have a few questions in relation to your comments. Apart from the boot mount point, what other mount points can be mounted read-only? I take it that every other mount point except /dev should be mounted nodev? How do you create a temporary partition that prevents data from persisting? I have no idea as yet what noexec does either but will most certainly explore it. – PeanutsMonkey Sep 1 '11 at 7:00
  • 1
    @PeanutsMonkey While this answer is correct, you are getting such a marginal return on your efforts that you would be much better off focusing your learning efforts elsewhere -- such as iptables and Linux file permissions. Once you have a solid understanding of how these work and how Linux operates in general, then you can return to partitions as a means of beefing up your system security. – Kromey Sep 1 '11 at 17:04
  • 1
    @PeanutsMonkey: Kromey is correct too. This answer is not useful for the new user. My answer increases security slightly at a drastic cost to usability (for most). It is useful for the paranoid sysadmin who wants that little extra security polish and is willing to pay the price for it. If you don't already know the implications of the changes described then making them will also make your life hell. Instead, I recommend learning all you can about setuid and setgid; that will take you very useful places. Your other questions might make good SU questions in their own right. – Slartibartfast Sep 2 '11 at 5:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.