If you look at the configuration files for any given Linux distro, you'll see that most of them belong to either the root user or to a specified system user. You'll also see that most of these files have read and write privileges for their respective owners, and read privileges for everyone else. This means that everybody and his brother can read most Linux system configuration files. Take, for example, this Apache web server configuration file:

[donnie@donnie-ca ~]$ cd /etc/httpd/conf
[donnie@donnie-ca conf]$ pwd
/etc/httpd/conf
[donnie@donnie-ca conf]$ ls -l httpd.conf 
-rw-r--r--. 1 root root 11753 Aug  6 09:44 httpd.conf
[donnie@donnie-ca conf]$

With that r in the "others" position, everybody who logs in, regardless of their privilege level, can view the Apache configuration.

So, is this a big deal? It really depends on your circumstances. Some configuration files, especially ones for certain PHP-based Content Management Systems (CMS) on a web server, can contain plain text passwords that the CMS must be able to access. In these cases, it's quite obvious that you need to restrict access to these configuration files. But what about other configuration files that don't contain sensitive passwords? 

For servers that only a chosen few administrators can access, this isn't such a big deal. But what about servers that normal, non-administrative users can access remotely via Secure Shell? If they don't have any sudo privileges, they can't edit any configuration files, but they can view them to see how your server has been configured. If they see how things are configured, would that help them in their efforts to compromise the system, should they choose to do so?

I have to confess, this is something that I hadn't given much thought about until recently, when I became a Linux consultant for a company that specializes in the security of Internet of Things (IoT) devices. With IoT devices, you have a bit more to worry about than you do with normal servers. Normal servers are protected with a high degree of physical security, while IoT devices often have little to no physical security. You could go your entire IT career without actually seeing a server, unless you're one of the few who have been authorized to enter the inner sanctum of the server room. Conversely, IoT devices are generally out in the open. 

The IoT security company that I work with has a set of guidelines that help harden IoT devices against compromise and attack. One of them is to ensure that all the configuration files on the devices are set with the 600 permissions setting. This would mean that only the owner of the files – generally either the root user or a system account – can read them. However, there are a lot of configuration files, and you need an easy way to change the settings. You can do that with our trusty friend, known as the find utility. Here's how you can do this:

  sudo find / -iname '*.conf' -exec chmod 600 {} ;

Here's the breakdown:

• sudo find / -iname '*.conf': This does exactly what you would expect it to do. It performs a case-insensitive (-iname) search throughout the entire root filesystem (/) for all the files with the .conf filename extension. Other filename extensions you might look for include .ini and .cfg. Also, because find is inherently recursive, you don't have to provide an option switch to get it to search through all the lower-level directories.
• -exec: This is what performs the magic. It automatically executes the following command on each file that find finds, without prompting the user. If you'd rather answer yes or no for each file that find finds, use -ok instead of -exec.
• chmod 600 {} ;: chmod 600 is the command that we want to perform. As find finds each file, its filename is placed within the pair of curly brackets ({}). Every -exec clause has to end with a semicolon. To prevent the Bash shell from interpreting the semicolon incorrectly, we have to escape it with a backslash.

If you decide to do this, test things thoroughly to ensure that you haven't broken anything. Most things work just fine with their configuration files set to a 600 permissions setting, but some don't. I've just performed this command on one of my virtual machines. Let's see what happens when I try to ping an internet site:

[donnie@donnie-ca ~]$ ping www.civicsandpolitics.com
ping: www.civicsandpolitics.com: Name or service not known
[donnie@donnie-ca ~]$

This looks bad, but the explanation is simple. It's just that in order to have internet access, the machine has to be able to find a DNS server. DNS server information can be found in the /etc/resolv.conf file, from which I've just removed read permissions for others. Without the read permissions for others, only someone with root user privileges can access the internet. So, unless you want to restrict internet access to users with root or sudo privileges, you'll need to change the resolv.conf permission setting back to 644:

[donnie@donnie-ca etc]$ ls -l resolv.conf 
-rw-------. 1 root root 66 Sep 23 14:22 resolv.conf

[donnie@donnie-ca etc]$ sudo chmod 644 resolv.conf 
[donnie@donnie-ca etc]$

Okay, let's try this again:

[donnie@donnie-ca etc]$ ping www.civicsandpolitics.com
PING www.civicsandpolitics.com (64.71.34.94) 56(84) bytes of data.
64 bytes from 64.71.34.94: icmp_seq=1 ttl=51 time=52.1 ms
64 bytes from 64.71.34.94: icmp_seq=2 ttl=51 time=51.8 ms
64 bytes from 64.71.34.94: icmp_seq=3 ttl=51 time=51.2 ms
^C
--- www.civicsandpolitics.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 51.256/51.751/52.176/0.421 ms
[donnie@donnie-ca etc]$

That looks much better. Now, let's reboot the machine. When you do, you'll get the following output:

So, I also need to set the /etc/locale.conf file back to the 644 permission setting for the machine to boot properly. As I mentioned previously, be sure to test everything if you choose to set more restrictive permissions on your configuration files.

As I've already stated, you might not always find it necessary to change the permissions of your configuration files from their default settings. But if you ever do find it necessary, you now know how to do it.

Okay – I think that this wraps things up for this chapter.