Linux Security: Mastering sysctl and sysctl.conf

Much of what we can do in securing our Linux host will require us changing configuration parameters in the procfs. The procfs in normally mounted below the /proc directory on our system and is a temporary  file-system of type proc. The contents present the running configuration of our server. Much of the procfs is read-only and cannot be changed, even by the root user, but some elements can be written to by root. It is these elements that we will look at and see their impact on hardening our Linux system. To truly manage the security of the system we have to learn the skills of Mastering sysctl and sysctl.conf.

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.

Download

Mastering sysctl and sysctl.conf

To understand the procfs we will first view the mountpoint /proc. We can use the mount command for this but we can also query the procfs directly. Current mounts are stored in the file /proc/self/mounts. These have links to it in the form of /proc/mounts and /etc/mtab. The mount command processes data directly from the file /proc/self/mounts. In the example we use grep to search this file for lines beginning with proc.

$ grep '^proc' /proc/self/mounts
 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0

Reading from left to right, the output shows that the proc device, the procfs, is mounted to the directory /proc. The 3rd entry shows that the file-system type is proc. Following this we have a comma delimited list of mount options before the final fields of 0 and 0, indicating that the file-system is not backed up or checked on system boot.

To view the files that link to /proc/self/mounts we can use the find command. As we already know, the symbolic links are located in the /etc and /proc directories, the example  used limits the search to just these 2 directories:

$ find -L  /etc /proc -maxdepth 1 -samefile /proc/self/mounts -exec ls -l {} \; \
 2>/dev/null
 lrwxrwxrwx. 1 root root 17 Mar  2 14:59 /etc/mtab -> /proc/self/mounts
 lrwxrwxrwx. 1 root root 11 Apr 24 11:23 /proc/mounts -> self/mounts

The option -L is used with find allowing us to follow symbolically linked files. We need this option to allow us to test that the link is pointing to the same file as our target. We set this up with -samefile /proc/self/mounts. The -maxdepth 1 option limits the search to the directories we specify. To view more details on the procfs you may use the man pages.

$ man 5 proc

The parameters that we can control are located in the /proc/sys directory and below. Using the tree command we can list the this structure. If you do not have the tree command then you can install the package, with either sudo yum install tree or sudo apt install  tree depending on your distribution. The option -L 1 limits the listing to just the top level. This works here for the graphic keeping it small. Feel free to omit the option to see a complete listing on your own systems.

$ tree -L 1 /proc/sys

To read the settings for the NIS domain name of your system, as an example, we can read the file /proc/sys/kernel/domainname file or key:

$ cat /proc/sys/kernel/domainname
 (none)

On my system this is currently has a value of (none) as you see. This is the NIS Domain Name and NOT the DNS Name of your system

The NIS Domain Name is not the same as your DNS Name. We use the NIS Domain Name here as a simple example to work with. In practical terms, NIS is less used these days so setting of this is purely for example. If you are not using NIS setting the Domain Name here will have no adverse effect on your system.

Another way of reading this value would be by using the tool sysctl. We can read all keys and their values with the -a option:

$ sysctl -a

The output is very verbose, 732 lines on my system. To drill down a little further we can use the –pattern option or its short form of -r along with -a:

$ sysctl -ar 'domainname'
 kernel.domainname = (none)

We now only see the one key and its value. If we want to see the value only, useful when we know the result delivers just one key add in the option -n:

$ sysctl -anr 'domainname'
 (none)

The option -r must be followed by the pattern, in this case we add the -n before the -r so we don’t upset the ordering of the options.

The supplied pattern is any extended regular expression. In this case the string would suffice but we could specify more elements to the key if required. In the following example, we specify the complete string for the key starting with kernel and ending with domainname. The dot is the separator which is part of the key name. As a dot is a meta-character in a regular expression we escape it to ensure that any special meaning is removed and we only match on the dot itself.

$ sysctl -anr '^kernel\.domainname
The sysctl command reads and write to the /proc/sys tree. As such we do not need to list these elements of a key. Instead of using the normal file-system path separator of the forward-slash a dot is used to create the hierarchy; hence the dots in the key name mentioned previously.
With sysctl the key kernel.domainname is equivalent to the file-system path of : /proc/sys/kernel/domainname
If we need to write to one of these keys we can use the command sysctl or a simple echo. Either way we need to working as root:
$ sudo sysctl -w kernel.domainname='theurbanpenguin.com'
 kernel.domainname = theurbanpenguin.com
Or
$ echo 'theurbanpenguin.com' | sudo tee /proc/sys/kernel/domainname 
 theurbanpenguin.com
If you are using sudo, rather than directly logged in as root, we cannot echo with redirection through to the file. Even if echo is run with sudo, the redirection falls back to your original permissions. This is why the example uses echo with a pipe to sudo tee. This way it is tee writing to the file with sudo rights as root.
Even though we have written the change to the running configuration it will not be persistent. To ensure that the system loads the correct NIS Domain Name on the next boot and on each subsequent boot we need to write the setting to the file /etc/sysctl.conf.
As well as the /etc/sysctl.conf file we have the extension directory of /etc/sysctl.d/. Both the file and the .conf files within /etc/sysctl.d/ provide a unified configuration repository to present to the Kernel upon system boot. Any valid configuration set within the repository is loaded upon boot. We can also force the loading of settings from these files with -p option of sysctl:
• sudo sysctl -p #Loads from the default file /etc/sysctl.conf
• sudo sysctl -p /etc/sysctl.d/01-file1.conf #Load from the specified file
• sudo sysctl --system -p #Loads from all files referenced at boot time, this includes

/etc/sysctl.conf and /etc/sysctl.d/*.conf
If we need to persist a setting then making the setting in the file and loading the file makes better sense than setting the configuration independently of the configuration file. Setting and loading from the file validates your persistent setting is correct and confirms that the setting will persist upon reboot.
Creating smaller modular files within the /etc/sysctl.d/ is an approach that is common in Linux administration and is preferred as administrator applied settings become separate from distribution supplied configuration. To persist the setting of the domain name we  will first return the configuration setting that we have made to the default:
$ sudo sysctl -w kernel.domainname='(none)'
 kernel.domainname = (none)
Yes, the value was set to literally (none) as opposed to being NULL or having no value. We will now create a new file /etc/sysctl.d/01-nis-domain-name.conf. We will use the echo and sudo tee method as before:
$ echo 'kernel.domainname=theurbanpenguin.com' \
   | sudo tee /etc/sysctl.d/01-nis-domain-name.conf
 kernel.domainname=theurbanpenguin.com
This will not have changed anything in the procfs just yet. We have only written to the configuration. To load this both now and ensuring a correct future load on reboot we issue the following command:
$ sudo sysctl -p --system 
 * Applying /etc/sysctl.d/01-nis-domain-name.conf ...
 kernel.domainname = theurbanpenguin.com
 ...
As our file had a suffix of 01 it is loaded first, we will also see other files loading. If this configuration key is reset in a later file the last setting made will be the effective settings. It is best not to duplicate settings or use higher numbers. I wanted to use a lower number to see the setting loading but I still would not want to duplicate any existing setting so double check the existing files with grep or similar to be sure.
As a final check we can read the setting from the procfs:
$ sysctl -ar 'domainname'
 kernel.domainname = theurbanpenguin.com
We now can be sure of the validity of the configuration and that it will load upon system boot. We have persisted  a configuration change within the procfs and understand better the operation of sysctl and /etc/sysctl.conf. As always you can refer to the man page of sysctl for more details:
$ man sysctl
The video follows:












 (none)

The sysctl command reads and write to the /proc/sys tree. As such we do not need to list these elements of a key. Instead of using the normal file-system path separator of the forward-slash a dot is used to create the hierarchy; hence the dots in the key name mentioned previously.

With sysctl the key kernel.domainname is equivalent to the file-system path of : /proc/sys/kernel/domainname

If we need to write to one of these keys we can use the command sysctl or a simple echo. Either way we need to working as root:

Or

If you are using sudo, rather than directly logged in as root, we cannot echo with redirection through to the file. Even if echo is run with sudo, the redirection falls back to your original permissions. This is why the example uses echo with a pipe to sudo tee. This way it is tee writing to the file with sudo rights as root.

Even though we have written the change to the running configuration it will not be persistent. To ensure that the system loads the correct NIS Domain Name on the next boot and on each subsequent boot we need to write the setting to the file /etc/sysctl.conf.

As well as the /etc/sysctl.conf file we have the extension directory of /etc/sysctl.d/. Both the file and the .conf files within /etc/sysctl.d/ provide a unified configuration repository to present to the Kernel upon system boot. Any valid configuration set within the repository is loaded upon boot. We can also force the loading of settings from these files with -p option of sysctl:

• sudo sysctl -p #Loads from the default file /etc/sysctl.conf

• sudo sysctl -p /etc/sysctl.d/01-file1.conf #Load from the specified file

• sudo sysctl –system -p #Loads from all files referenced at boot time, this includes
/etc/sysctl.conf and /etc/sysctl.d/*.conf

If we need to persist a setting then making the setting in the file and loading the file makes better sense than setting the configuration independently of the configuration file. Setting and loading from the file validates your persistent setting is correct and confirms that the setting will persist upon reboot.

Creating smaller modular files within the /etc/sysctl.d/ is an approach that is common in Linux administration and is preferred as administrator applied settings become separate from distribution supplied configuration. To persist the setting of the domain name we  will first return the configuration setting that we have made to the default:

Yes, the value was set to literally (none) as opposed to being NULL or having no value. We will now create a new file /etc/sysctl.d/01-nis-domain-name.conf. We will use the echo and sudo tee method as before:

This will not have changed anything in the procfs just yet. We have only written to the configuration. To load this both now and ensuring a correct future load on reboot we issue the following command:

As our file had a suffix of 01 it is loaded first, we will also see other files loading. If this configuration key is reset in a later file the last setting made will be the effective settings. It is best not to duplicate settings or use higher numbers. I wanted to use a lower number to see the setting loading but I still would not want to duplicate any existing setting so double check the existing files with grep or similar to be sure.

As a final check we can read the setting from the procfs:

We now can be sure of the validity of the configuration and that it will load upon system boot. We have persisted  a configuration change within the procfs and understand better the operation of sysctl and /etc/sysctl.conf. As always you can refer to the man page of sysctl for more details:

The video follows: