An Example: Protecting a Freshly Installed Package

For this example we added a package called my_package.rpm. my_package.rpm has a configuration file in /etc, a binary in /sbin, a log is kept
/var/log/my_package.log and stores user data in /var/lib/my_pack 
age/. my_package.rpm also requires setuid and setgid access. Without reconfiguring LIDS this application won't function properly. Here is what needs to be done to add this package to your LIDS configuration. Issuing the following command will give you a list of the files an RPM uses. Though it won't tell you if it needs, read, write and/or append access to them.

rpm -qpl package_name.rpm

The first thing we want to do now is protect the configuration file. The configuration file never needs to be changed by the program so we can give it READ access only. If you want to make changes in the future simply disable LIDS, make your changes and enable LIDS. Here is how to protect our config file for READ only access:

lidsadm -A -o /etc/my_package.conf -j READ

Now the file is in the LIDS configuration file and set as read only. We used the -A option to ADD a new object. The -o object is the file my_package.conf and it's -j attribute is READ. Valid attributes are READ, WRITE, APPEND, DENY, and IGNORE.

• [NOTE:]These are case sensitive and therefore must be written in all upper case letters.

We have successfully protected the configuration file. Next we will tackle the log file. The log file is simply a file that maintains a list of program events. The file never changes previous information and therefore can be set to APPEND only. So we issue a similar command as the one used for the configuration file:

lidsadm -A -o /var/log/my_package.log \

           -j APPEND

This command is almost the same as above except we set the log file to APPEND. Next we want to protect the user data. We want to be able to read and write to the user data, but we don't want root to have the ability to view the data, since it could be private information. This is also a secure method of protecting sensitive data from an intruder, if they gain root access. First we have to deny everybody access from the user data. There could be a slight problem if the user data directory contains dozens, maybe hundreds of files. This could be quite cumbersome typing in each file name into lidsadm. Well the lidsadm program allows you to protect a directory and everything under it. So now lets protect the directory:

lidsadm -A -o /var/lib/my_package/ -j DENY

Now everyone is denied access to that directory and everything in it. In fact, if you get a directory listing of /var/lib the my_package/ directory will not even be visible. So now it's safe. Too safe now actually. You have to give your my_package binary access to the data for it to run properly. To give the binary, and only the binary, access to the data, we can issue this command:

lidsadm -A -s /sbin/my_package_binary \ 
        -o /var/lib/my_package -j IGNORE

Once that is issued it gives /sbin/my_package_binary full access to everything in the /var/lib/my_package directory. In the example above we -A added a new -o object but this time linked it to a -s subject. So now the user data is completely protected and is not hindering the usage of the my_package application.

Finally we need to protect the binary from being deleted. So we can simply set it as read only. We can use the same command that we used for the config file:

lidsadm -A -o /sbin/my_package_binary -j READ

When initially securing the system the entire /sbin directory was protected. To add /sbin/my_package_binary separately you can do what was done above or you can update all the items in the LIDS config. Doing this will add the /sbin/my_package_binary to the config

lidsadm -U

We are now left with one last problem. The my_package_binary needs setuid and setgid permissions to run properly. By default the setuid and setgid capabilities are disabled by LIDS (more concerning capabilities will be explained in the following sections). Using lidsadm you can assign capabilities to a specific file. The lidsadm command is similar to adding a file:

lidsadm -A -s /sbin/my_package_binary -t \ 
        -o CAP_SETUID -j INHERIT

lidsadm -A -s /sbin/my_package_binary -t \ 
        -o CAP_SETGID -j INHERIT

Now the /sbin/my_package_binary will inherit the setuid and setgid capabilities in the kernel giving it permission to use. The -t flag is used to tell lidsadm the object is special, or not a file in this case.

To make certain everything in your LIDS configuration is set properly issuing a:

lidsadm -L

will present you with a list of all the items in the configuration and their attributes. You must have lidsadm turned off to use this option. Now the entire package is done. Reload the config into LIDS and finally enable LIDS again:

lidsadm -S - +RELOAD_CONF

lidsadm -S - +LIDS

Now you are ready to go.

When LIDS is initially configured for EnGarde a script was created that contains all file attributes. This script can be run at any time to reset you back to the system defaults. Additionally you can create your own script file for any additions you make. This makes it much easier if you make a mistake and have to start over from scratch. A simple command to launch your script will put you back where you were instead of typing everything back in. If you are using the GD WebTool this is already done for you. The script can be something basic, here is a sample script using the example above:

#!/bin/bash

#

### LIDS configuration - 9/13/00

#

#### Configuration for my_package.rpm

#

 lidsadm -A -o /etc/my_package.conf -j READ

 lidsadm -A -o /var/log/my_package.log -j APPEND

 lidsadm -A -o /var/lib/my_package/ -j DENY

 lidsadm -A -s /sbin/my_package_binary \

            -o /var/lib/my_package -j IGNORE

 lidsadm -A -o /sbin/my_package_binary -j READ

 lidsadm -A -s /sbin/my_package_binary -o CAP_SETUID \

            -j INHERIT

 lidsadm -A -s /sbin/my_package_binary -o CAP_SETGID \

            -j INHERIT

#

#### End my_package.rpm configuration

You can even add this to your /etc/rc3.d/ (/etc/rc.d/rc3.d/ for RedHat systems)so the LIDS configuration is freshened on every boot up. Just make sure it's done before the kernel is sealed (lidsadm -I). More information about sealing the kernel is explained in later sections.

If this package is ever removed you will have to delete the entries. Using the script method above, delete out all the entries then lidsadm -Z and run all the scripts again. Otherwise you can issue a lidsadm -D for each file entry you have. For files with multiple entries, you only need enter it in once. Lidsadm will delete all entries for that file.