I recently acquired a netbook to play with, and I want to install Kali Linux so I can start learning about network security and exploit development. I want to use this to learn as much about security as I can.

What is the best way to partition a linux box so that it is most resistent to a security risk? Is a single partition containing all of the folders in linux really that bad?

Extra points if you can go into details about the threats possible. I want to learn as much as possible.

  • 4
    Can't wait to see how you plan to distribute those extra points you are promising. I'm giving you a +1 and hope that ends up in a bounty, you've managed to gather at least a couple of good answers well worth it, even if the question is rather vague.
    – TildalWave
    Commented Jul 12, 2013 at 1:36
  • 1
    Just one partition on read-only physical media.
    – tylerl
    Commented Jul 16, 2013 at 21:25

6 Answers 6


Please keep in mind the Holy Trinity of Information Security: C(onfidentiality), I(ntegrity), and A(vailability). So when we talk about configuration hardening you need to consider the technology you're working with, the information being protected, how the information is used within the organization, and the threats. Based on those answers, and possibly others, you can begin to determine which of the tenants are most important and what to focus on.

At the filesystem level you're typically most interested in Integrity and Availability. The Confidentiality of the information should probably be handled at a different layer, but how you lay our your filesystems and how you use them should make sure that the information is both trustworthy and is always available when it's needed.

One thing to keep in mind when laying out your partitions are failure modes. Typically that question is of the form: "What happens when partition x fills up?"

What happens if your partition storing the OS is full? Strange things sometimes happen when / fills up. Sometimes the system hangs. Sometimes no new login sessions can occur. Sometimes the system refuses to boot.

Of all the failure modes this one is the hardest to strictly characterize as its symptoms are the most likely to change based on OS, kernel version, configuration, etc. Some filesystems, particularly the ext line, reserve a certain amount of space when the filesystem is created. This reseved space can only be used by the root user and is intended to allow the systems administrator to still operate and clean out space.

What happens if your partition storing logs is full? You lose auditing/reporting data and is sometimes used by attackers to hide their activity. In some cases your system will not authenticate new users if it can't record their login event.

What happens on an RPM based system when /var is full? The package manager will not install or update packages and, depending on your configuration, may fail silently.

Filling up a partition is easy, especially when a user is capable of writing to it. For fun, run this command and see how quickly you can make a pretty big file: cat /dev/zero > zerofile.

It goes beyond filling up partitions as well, when you place locations on different mount points you can also customize their mount options.

What happens when /dev/ is not mounted with noexec? Since /dev is typically assumed to be maintained by the OS and only contain devices it was frequently (and sometimes still is) used to hide malicious programs. Leaving off noexec allows you do launch binaries stored there.

For all these reasons, and more, many hardening guides will discuss partitioning as one of the first steps to be performed. In fact, if you are building a new server how to partition the disk is very nearly exactly the first thing you have to decide on, and often the most difficult to later change. There exists a group called the Center for Internet Security that produces gobs of easy to read configuration guides. You can likely find a guide for your specific Operating System and see any specifics they may say.

If we look at RedHat Enterprise Linux 6, the recommended partitioning scheme is this:

# Mount point           Mount options
/tmp                    nodev,nosuid,noexec
/var/tmp                bind (/tmp)
/home                   nodev
/dev/shm                nodev,nosuid,noexec

The principle behind all of these changes are to prevent them from impacting each other and/or to limit what can be done on a specific partition. Take the options for /tmp for example. What that says is that no device nodes can be created there, no programs can be executed from there, and the set-uid bit can't be set on anything. By its very nature, /tmp is almost always world writable and is often a special type of filesystem that only exists in memory. This means that an attacker could use it as an easy staging point to drop and execute malicious code, then crashing (or simply rebooting) the system will wipe clean all the evidence. Since the functionality of /tmp doesn't require any of that functionality, we can easily disable the features and prevent that situation.

The log storage places, /var/log and /var/log/audit are carved off to help buffer them from resource exhaustion. Additionally, auditd can perform some special things (typically in higher security environments) when its log storage begins to fill up. By placing it on its partition this resource detection performs better.

To be more verbose, and quote mount(8), this is exactly what the above used options are:

noexec Do not allow direct execution of any binaries on the mounted file system. (Until recently it was possible to run binaries anyway using a command like /lib/ld*.so /mnt/binary. This trick fails since Linux 2.4.25 / 2.6.0.)

nodev Do not interpret character or block special devices on the file system.

nosuid Do not allow set-user-identifier or set-group-identifier bits to take effect. (This seems safe, but is in fact rather unsafe if you have suidperl(1) installed.)

From a security perspective these are very good options to know since they'll allow you to put protections on the filesystem itself. In a highly secure environment you may even add the noexec option to /home. It'll make it harder for your standard user to write shell scripts for processing data, say analyzing log files, but it will also prevent them from executing a binary that will elevate privileges.

Also, keep in mind that the root user's default home directory is /root. This means it will be in the / filesystem, not in /home.

Exactly how much you give to each partition can vary greatly depending on the systems workload. A typical server that I've managed will rarely require person interaction and as such the /home partition doesn't need to be very big at all. The same applies to /var since it tends to store rather ephemeral data that gets created and deleted frequently. However, a web server typically uses /var/www as its playground, meaning that either that needs to be on a separate partition as well or /var/ needs to be made big.

In the past I have recommended the following as baselines.

# Mount Point       Min Size (MB)    Max Size (MB)
/                   4000             8000
/home               1000             4000
/tmp                1000             2000
/var                2000             4000
swap                1000             2000
/var/log/audit       250

These need to be reviewed and adjusted according to the system's purpose, and how your environment operates. I would also recommend using LVM and against allocating the entire disk. This will allow you to easily grow, or add, partitions if such things are required.

  • Max 8 GB for the root filesystem? And max ~20 GB allocated to partitions in total, including /home? I agree, those definitely need to be reviewed in light of the system's purpose. My home system admittedly doesn't follow this partitioning scheme exactly (in particular, /var is baked into /) but I'm using about 12 GB on / so far without too much excess cruft installed. A max size around 8 GB would almost definitely be cramped for any multi-purpose system; I'd say give / around 20 GB, more if you can afford it, so that you have room to grow. The root fs is the last fs you want filling up.
    – user
    Commented Jul 12, 2013 at 8:14
  • 2
    @MichaelKjörling: Those are just starting points. On a single purpose server, which is what most servers should be, you don't actually have very much in /. I rarely see it get above 2GB on a properly partitioned server, almost never above 5GB. In fact, I thought I had addressed the / filling up, looks like I forgot it. That's also a bit part of moving /var onto it's own partition. It's fairly easy for an attacker to fill up your logs causing a DoS.
    – Scott Pack
    Commented Jul 12, 2013 at 12:45
  • Yes, I know you said baseline, but I was still a bit surprised at the numbers. And the OP said that this is about "a netbook to play with", not a single-purpose server. A home system isn't exposed to the dangers of the Internet in quite the same way as a publicly-accessible server, even if that server only does one thing.
    – user
    Commented Jul 12, 2013 at 12:56
  • 3
    @MichaelKjörling: Which is exactly why they're baselines with guidance. They need to be adjusted to fit your environment. He also said he wanted to use Kali which, while much better than Backtrack, also puts things in weird and non-standard places. As I recall much of it ends up in /opt, which would need to be created since it's not in the above guidance would end up in / anyway. Opt is one of those weird ones that is part of the standard, but randomly used.
    – Scott Pack
    Commented Jul 12, 2013 at 13:18

The split into one or several partitions is not really a problem of security but of reliability. The idea is that if one of your partitions is crashed, then you lose the contents of that partition, but the other partitions are fine. Also, if you fill up that partition, then other partitions are unaffected. Each partition can have its own filesystem, and not all types of filesystems are equivalent with regards to performance in various contexts (although most filesystems will be mostly as good as each other in most contexts). On some PC, the boot process may have trouble access farther than the first few gigabytes of the disk due to historical peculiarities of this architecture, which are too horrifying to be recalled here; thus, /boot is often better set as a separate partition of limited size and located first in the disk.

If you want to apply partition-level encryption, then you may run into trouble if you encrypt too much -- namely, the code which does the decryption must be located outside of the said partition. This depends a lot on the actual encryption product (some can embed the decryption code in the bootloader).

Note that the more you split your disk into partitions, the less flexible the whole thing becomes. When a partition fills up, it is full and stays that way, even if other partitions have free space (LVM can help cope with that, so you might want to say "yes" when the OS installer asks whether you want to use LVM). The more partitions you create, the more probable and hard this problem becomes.

The easy and safe path is to let the OS installer choose the partitions as it thinks best. Don't go on changing partition sizes until you have some precise knowledge and experience of what this entails. Don't forget to make regular backups. It is expected that, after a few months, you will want to reinstall your OS to "do it right", and that's not necessarily a bad idea, so don't sweat it. This is a learning tool, not a server which will go into production.

  • I used to always let the OS installer chose partition sizes (apart from home when they don't create separate partition), but recently I installed Opensuse Tumbleweed and after just a few weeks I couldn't even boot into the graphical interface anymore because / was full... Didn't even install that many programs :/
    – Shautieh
    Commented Sep 23, 2016 at 9:42

I'd look at this a different way than the other responders so far: if you are looking at a bunch of exploits, then all the threats are possible and sandboxing the system where you do that as much as possible seems like a useful precaution. Xen is one easy way to do that. It can use disk images on another file system, but if you know you are going to use it I'd suggest leaving separate disk partitions (and make sure they don't get automounted on your Dom0).

I don't know how well Kali works as Xen Dom0. Ubuntu at least seems to have issues. You might consider leaving room for XenServer or another specialized Xen Dom0 build. [Edit: I'm not sure what netbooks are like these days but I'm guessing XenServer isn't really targeting them... Maybe some other simpler distribution that works well with Xen as Dom0. You may be able to set up a Kali install that runs either standalone or as a DomU if looking at exploits is a less common task.]

On BSD systems I've heard of hardening methods involving partitioning to mount as much as possible read only and using immutable flags. I'd assume there are at least some Linux systems where a similar setup is possible, however it looks like Kali is Debian based and my sense is that you can't really do that on Debian [edit: unless you mount a writeable FS over it, which would still be awkward to maintain over time]. In any case, I wouldn't suggest this for a general purpose machine and only bring it up in case you are more generally interested in all the ways partitioning might be used. For your purpose, put the threats on a system you can delete and recreate easily.


There is a lot of good information in som eof these responses, but I'm not sure they really address your specific requirements. Given that your stated aim is to learn and you plan to use this system for experimentation and playing with Kali Linux to gain increased understadning of security related matters, I would aim for a system which is quick and easy to reinstall rather than one which is hardened or secure. Once you have gained knowledge and experience with the system, you will e in a far better position to make the decisions as to what configuration best meets both your needs and fits best with your style of working etc.

Some things to be aware of which have not been mentioned by others.

  • Much of the advice on partitioning is partially outdated and can conflict with some modern techniques used to speed the boot process, such as prelinking and preloading or caching.

  • Until you have a really good idea of how you will use a system and how that system is configured, it is almost impossible to get partition sizes correct. As pointed out by another user, if Kali uses /opt for example, either you must create an opt partition or /opt will use space allocated to /. If you don't know if it does or if you don't know what it uses it for, then you cannot judge how large to make the partition.

  • The requirements you have for learning are very different to the requirements you would have for a production pen testing or security auditing/investigation system. When learning, what you often need to do is quickly and easily return the system to a known, good (factory default) state. For this reason, I would often use a virtual image, but this isn't really feasible on a netbook. For a production, pen testing, security auditing etc system, I would want something quite protected. I would probably setup Kali on a read only media with some dedicated (and wipeable) storage support. This would increase my confidence that my system won't be modified or altered when being used in a hostile environment and I can have increased confidence that whenever I reboot the system, it will return to a known configuration etc.

I think you will find Kali Linux quite a challenge to start with. Saying you are going to learn security by using Kali is a little like saying your going to lern to fly by getting into a fighter jet. How easy you will find this will depend on your Linux experience and your familiarity with Debian based systems. I would just go with a standard install with just a single partition which can easily be wiped and re-installed. Later, depending on what you find and decide to do, you can consider more robust and secure setups. Keep in mind also that Kali is actually relatively new and still has its own teething problems. Sticking wiht a default install will help reduce the likelihood of triggering bugs in the Kali setup, which may be really confusing when you are learning. Bottom line, keep it simple to start with.


All of the other answers are good starting points.

In the olden days (early 90s) disks were small enough that we actually had the option of installing the unix and placing the /usr on its own physical disk. After the installation we could set a read only jumper on the physical disk. Back in those days of wide open plain text everything on the internet, it was common to get rooted. The nice thing about this configuration is that even once you were rooted, you were protected against files in /usr changing.

You could conceivably do something similar by making /bin, /sbin, and /usr on filesystems which are ro,exec and having all other filesystems noexec.


I seperate boot usr vat var/tmp tmp var/service (like ldap and www) var/lib/mysql home and individual dirs at an own partition. You can use special mount option and grsec kernel features with that. Maybe you wish to decrypt some partitions. And maybe you use your own Iittle kernel.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .