As we continue are study into Linux Security and the LPIC-3 303 exam we now take a look at controlling the amount of resources that we make available to our users. We all know that if we give then everything then they will use everything. To maintain the integrity of the Server we need to ensure our users cannot be too greedy . This is where we can use ulimit to control access to the precious resources of a server.
Each objective is available to view online. However if you prefer to have all the content in one place and study from an eBook then the objective ‘LPIC 3 Linux Security 326.1 Host Hardening’ is now available to download for just £0.99.
Ulimit and the limits.conf file
We start by investigating the command ulimit where we can display and set limits before we move onto static configuration which we set in the /etc/security/limits.conf file.
The command ulimit is a shell builtin, to gain access to help we can use the BASH man page and search for ulimit.
$ type ulimit ulimit is a shell builtin $ man bash
When used on its own without options or arguments ulimit will display the soft file blocks limit for the current user
$ ulimit unlimited
To see all soft limits we can use :
$ ulimit -a .....
To see all hard limits we can use:
$ ulimit -Ha ...
A hard limit cannot be increased by a non-root user once it is set; a soft limit may be increased up to the value of the hard limit. The hard limit CAN be reduced by a standard user.
If we want to see a specific resource limit we just need to implement the correct option. The -a option will print all limits and their specific options. To see the soft limit configured for the number of processes we can access :
$ ulimit -u 3843
Or, specifically addressing the soft limit
$ ulimit -Su 3843
The hard limit is the same on my Ubuntu 18.04 server. This limits me to a maximum of 3843 processes running at the same time. Like many of the default resources this is probabaly a little high. Let us show how this can cause issues on your server. Our server only has 1GB of RAM and this memory will run out well before we hit the maximum number of available processes. We can demonstrate this by a simple shell script. This script is meant to be destructive, at least to a degree, so take care on your own systems.
We will create a shell script that calls itself, this means that we will keep creating new processes until the system gives up.
#!/bin/bash echo $ $0
The script will print the current process ID before calling itself. Each time it is called a new BASH shell is opened.
Executing the script will show the creation of new processes for a little while but then my system shows memory issues before we hit the 3843 processes. This is why we should limit access to all resources to more realistic levels. This may be a litttle hit or miss to start so you can test on sample users before implmenting across more users.
First, if we change our own limit:
$ ulimit -Su 200 $ ulimit -Hu 400
These setting configure a soft limit of 200 processes and an upper limit of 400 processes. The upper limit is maximum level that I can raise the soft limit to. As a standard user I cannot increase the hard limit.
Executing the script now and we will stop afetr the 200 processes and before the memory is exhausted.In this way we have protecetd the server and maintained the availabilty of the server to all users.
Configuring these transient limits are useful for testing but once we want to implement a longer test cycle we can setting to the /etc/security/limits.conf file. This is where the administrator implements restrictions. The file is well documented, we can impose restrictions for users, groups and all users. The username for a user, groups are denoted with the @ prefix and the * is used for all users. Adding the following two lines will implement the same settings we made before for the user account named ubuntu.
ubuntu soft nproc 200 ubuntu hard nproc 400
The settings become effective on the next login for the user. Once the correct settings have been identified then you can consider rolling the configuration to more users using groups or the asterix. We have also only considered the single resource here, the number of processes. Each server resource can be considered valuable and should be protected from misuse.