Securing your system with Linux Intrusion Detection System
When LIDS is running, it can occupy one of three states. As its name implies, the BOOT state is when the system is booting up and initializing. This state also includes startup for system services (daemons). The POSTBOOT state is after the system has booted and it is running "normally." Finally, the SHUTDOWN state is when the machine is shutting down. Each of the states has its own configuration files located in /etc/lids.
The different states are necessary because you likely want system services to access different files and directories during startup and shutdown. PID (Process Identification) files, for example, must be written when the system starts up; however, it might be considered a security violation to write these files during normal operations. Therefore, PID files are only accessible in the BOOT state. (Note that you can also run a LIDS Free Session at any time to write these files.)
The BOOT state occurs naturally while the system is booting, and you have no reason to go specifically into this state. The POSTBOOT state, which represents the normal operating mode, is reached by sealing the kernel. To switch to the SHUTDOWN state manually, you can enter the following command line:
lidsadm -S -- +SHUTDOWN
LIDS is not really running until the kernel is sealed. By default, the kernel is not sealed automatically. You can seal the kernel with an init script that is configured to run as the last script. In one of the virtual machines, you can download the init script zzz-bootup-end, which is started as S99zzz-bootup-end – so it more than likely ends up running last. This small script simply runs:
lidsadm -I +TPE
The -I option initializes LIDS (sealing the kernel), and the +TPE activates TPE mode.
The lidsadm command is the primary administrative tool, and it is useful simply to think of it as managing LIDS as a whole. In older versions of LIDS, lidsadmin contained all of the administrative and configuration functions, including setting or clearing ACLs, sealing the kernel, or turning off LIDS entirely. In newer versions, certain functions have been redefined as "configuration," and these functions are included in the new lidsconf command. As its name implies, lidsconf (Figure 1) is used to configure LIDS. For details on the various options for each of the programs, take a look at the appropriate man page.
The changes made by LIDS are swift and all-encompassing. Once you activate the LIDS kernel module, you will quickly discover that even some of the more basic functions are no longer possible. For example, you might not even be able to stop the CUPS printer service because even root does not have permission. This result is entirely consistent with the philosophy of ACLs – if you do not have access to the appropriate files and directories, you won't be able to delete a PID file when a service is stopped. Of course, you can change this configuration, but in any case, make sure you're prepared before you throw the switch.
Another common use of the lidsadm command is to create a LIDS Free Session (LFS). Creating an LFS is necessary when you need to make changes to LIDS itself once it is running. To create an LFS, enter the following command:
lidsadm -S -- -LIDS
To re-enable LIDS in the current sessions, change the option to +LIDS. Note that this command will result in a prompt for the LIDS password, which you set during the installation.
For files and directories that must be protected in all states, you can use GLOBAL ACL, although it is also possible to define a global ACL and still have it overridden in a specific state. Overriding a general configuration with a more specific configuration is a basic principle of LIDS.
Setting up ACLs
The LIDS ACLs are supplemental to any permissions the base operating system applies. This includes standard Unix permissions, as well as any ACLs the respective filesystem provides. The layers of overlapping ACLs can be confusing if you're accustomed to the simplicity of traditional Unix permissions.
LIDS ACLs support several different types of permissions. DENY is absolute, meaning that nothing can even see the object. READ means the object is read-only and cannot be modified. APPEND lets you add to files, but you cannot change them otherwise. This option is useful for logfiles that are regularly written to without the need for later modification. If you are given WRITE access to an object, which allows you to make changes, the object is more or less unprotected.
It is important to note that when an ACL is applied to a directory, the permissions are recursive. This means that if you want to protect an entire directory, you do not need to mention every file, just the parent directory. However, you can define an ACL for a specific file that would then overwrite the general ACL for the directory.
ACL restrictions consist of a subject, which is a program, library, or module, and an object, which is a file or capability to which the ACL applies. As mentioned before, lidsconf is used to configure ACLs. The basic syntax is as follows:
lidsconf -A acl_type -s subject -o object -j action
The acl_type is any one of the three states or the (default) option GLOBAL, which is then valid for all states. An action is one of the permissions types discussed above.
If you want to configure all files in the /var/log directory so that they can only be written to, you could run the following command:
lidsconf -A -o /var/log -j APPEND
In this example, because the acl_type is blank, it defaults to GLOBAL. The object is the /var/log directory, and I have set APPEND permissions. Because I did not specify a subject (a program), LIDS will default to all programs, libraries, and modules unless a limitation is specifically defined elsewhere.
The option of imposing ACLs on a directory that affects the files underneath (and can be overridden by more specific ACLs) is useful in many cases. For example, you could define a directory to be invisible (i.e., DENY) but allow access to a specific number of files. To override the APPEND privilege with WRITE for a specific program, the command might look like this:
lidsconf -A -s /usr/local/bin/myprogam -o /var/log/ -j WRITE
Explicitly listing the subject (/usr/local/bin/myprogram) ensures that no other program can write to the /var/log directory to move or rename files. In this case, the general ACL would say that nothing could write to the directory, but the more specific ACL would allow writing only for the program specified as the subject. Another common example is to deny all programs access to /etc/shadow, so that not even root can see the encrypted password but allow access for specific programs such as login or sshd.
Also, it is important to keep in mind that security is not just about file permissions, but about the programs doing the accessing as well. If the accessing program is insecure, then all bets are off. To ensure the security of the entire system, LIDS insists that accessing programs (i.e., the subjects) be protected as well. For example, I could not grant access to the login program unless it is protected by an ACL itself. (Note that /bin/login is already protected by default.)
Permissions and Capabilities
One feature that sets LIDS apart from traditional ACLs is that an object does not need to be a file or directory. Instead, it can be a capability, such as the ability to bind to a specific port (CAP_NET_BIND_SERVICE). Without this capability, network services could not bind to their respective ports. For capabilities (as apposed to files and directories), LIDS provides two additional permission types: GRANT and DISABLE. As the name implies, GRANT gives the capability to the specific subject.
Assuming you have a web server on your system, the command for granting a certain capability to the web server program might look like this:
lidsconf -A -s /usr/sbin/httpd2 -o CAP_NET_BIND_SERVICE 80 -j GRANT
In the preceding command, note that the port number (80) follows the capability. This requirement limits the httpd2 binary to only port 80. Therefore, it would be impossible to run httpd2 on any other port or let any other binary bind to port 80. On many systems, what is actually started is a symbolic link. Because LIDS is based on inode, the program that actually runs (e.g., httpd2-prefork) might not run because it was not granted the necessary capability.
The LIDS ACLs are based on the inode of the file, which you can see in the respective .conf file. Internally, LIDS stores the list of protected files on the basis of the filesystem and inode. The advantage here is that the hard links to files are automatically protected, without the need to set each one individually. The disadvantage is that when a file is first moved and then replaced with a newer version, you need to update the inode list with
to update the configuration files, and then
lidsadm -S -- +RELOAD_CONF
to reload the current configuration into the kernel.
Weird data transfer technique avoids all standard security measures.
FIDO alliance declares the beginning of the end for old-style login authentication.
Legendary Uber-distro splits over the systemd controversy.
One of CeBIT’s most successful forums returns in 2015.
A new study says it is possible to unmask 81% of TOR users.
Redmond joins the revolution by turning the .NET Core Runtime into a GitHub project.
Users only had 7 hours to update before the intrusions started.
It's official: The new web arrives