How and why it is necessary to break a disk in niksa

One of the fairly common questions on various near-Nikon resources is the question of which disk mapping scheme to use. In appearance, a simple question is actually fraught with many pitfalls. If, of course, the case is about servers. On desktops, everything is much more boring and gray.

There is no universal solution to this issue, there are simply some aspects that should be followed when choosing a breakdown scheme.

User restriction

All sections where a regular user has write permissions (/ home; / tmp; / var / tmp) must be placed in separate sections. With this step, we immediately kill the whole family of hares:

• when reinstalling the system there is no need in a hurry to transfer user data to other media / restore what was dug up from rotten backups a year ago
• we get the opportunity to mount these partitions with noexec so that malicious kulhackers do not run all kinds of rubbish on your system. I remind you that noexec does not save shell scripts.
• we are saving ourselves from a hard-link attack (this is when a vulnerability is found in a package, you successfully demolish it, but the vulnerability remains because the attacker created a hard link to the vulnerable file). Here and here you can read more.
• we can use the ext2 file system in / tmp (journaling is useless here, because in the event of a failure, nothing needs to be restored)

We protect the system from failure in work due to lack of disk space

It is worth remembering that we have a wonderful / var / log, which loves clogging logs to the eyeballs, insatiable users who always lack disk space and temporary folders who like to clog with millions of temporary files that no one removes. All such sections (/ var; / home; / tmp) should also be taken out of the root.

Sticks in the wheel for attackers

Quite a dubious measure, but more than once I met a similar recommendation: mount / usr in readonly.
However, we also create certain inconveniences for ourselves: it’s so simple to update the system now so it will not work. However, for example, in GNU / Debian, this is bypassed by adding to /etc/apt/apt.conf: True post-invoke does not always work. Sometimes you have to use lsof + L1 to figure out who is to blame for the fact that / usr is busy and cannot be remounted in ro.
DPkg
{
Pre-Invoke { "mount /usr -o remount,rw" };
Post-Invoke { "mount /usr -o remount,ro" };
};

swap. Is it necessary or not?

Quite often recommendations to make a swap equal to double the size of RAM. On servers, where it happens on 64-128GB (or even more) of RAM, it even sounds silly. There is no particular need for a swap on systems now. Well, only if you do not want to use hibernation. However, this is the prerogative of laptops, not servers.

Mount options

A very important point that you should pay attention to. In addition to the aforementioned noexec, nosuid and nodev should be installed on user partitions. You can also reduce disk load using the noatime or relatime options and by increasing the commit time commit = 60 (the default commit time is 5 seconds).

Summary

These aspects are advisory in nature, there are no strict rules on this issue. It all depends on personal preference.
However, I would like to draw a certain line:

• Try to move / root, / home, / tmp, / var to separate sections from the root.
• Use lvm to avoid biting your elbows in the future if you suddenly need to enlarge a section.
• Do not forget about the mounting options, sparing disks. We don’t want them to fly out.
• Do not forget to remove the reserve for the root on the rendered partitions, because it is no longer necessary (tune2fs -m 0 / partition)