Testing LIDS before Applying It to Your System

You can use LIDS to secure your computer, but it’s a good idea to experiment in a UML virtual computer first. Fortunately, LIDS is bundled with the ADIOS UML distribution we talk about in Technique 15.

A quick way to find out just how good your potential system configuration will work for you is to make a practice run inside a UML VM.

Here’s an overview of how testing in a UML VM works:

1. Set up the system in a confined environment

(a UML VM).

See Technique 15 for details on downloading, installing, and setting up LIDS in a UML VM.

2. Test the LIDS configuration.

You find the details on configuring LIDS in the sections that follow.

3. If you like the LIDS configuration in the VM, copy the access control list to your system.

A LIDS-enabled kernel runs in two distinct modes. In secure mode (called LIDS On mode), all the access control rules that you define are enforced. In nonsecure mode (LIDS Off), you’re running a standard Linux kernel; LIDS has no effect in nonsecure mode. The easiest way to manage LIDS is to boot into LIDS Off mode, make the configuration changes that you want, and then boot back into LIDS On mode. Throughout this technique, we assume that you’re using the ADIOS UML distribution. To boot in LIDS On mode, just open the KDE Menu and choose User Mode Linux LIDS On; to boot in LIDS Off mode, choose User Mode Linux LIDS Off.

Understanding the LIDS

Access Control List

LIDS is controlled by a set of configuration files, typically stored in the /etc/lids directory. When you configure LIDS, you add access control entries to an access control list (we use the terms ACE and ACL, respectively). An ACE controls access to a file, a directory tree, or a superuser capability. The ADIOS VM is preconfigured with a reasonable set of access rules that you can use as a starting point.

To view your current LIDS configuration (the access control list), type in the command lidsconf -L. You see a list that looks something like this (we’ve modified the following example to fit on the page):

Subject ACCESS inherit time Object

------------------------------------------

Here’s how to interpret the configuration info:

Subject: The first (leftmost) column shows the subject. If you see a program name in the subject column, the ACE controls that specific program. If you see Any file in the subject column, the ACE controls all programs.

ACCESS: The second column shows how the subject can access the object.

Inherit: The inherit column displays a 1 for ACEs that are inherited by the subject’s child processes and a 0 for ACEs that are not inheritable.

Time: The time column shows the hours during which the ACE will be enforced.

Object: The second-to-last column shows the object. The object is the thing that you’re securing. In the sample listing, the first ACE controls access to the /bin directory (and all files and subdirectories underneath /bin). If you see the same object listed more than once, the first ACE generally restricts access for all subjects, and the other ACEs grant exceptions for specific programs. An object can be a file or directory, or a capability. When you secure a directory, you secure everything underneath that directory as well.

Parameters: The last (rightmost) column lists ACE parameters. ACE parameters are rarely needed. In fact, you can include parameters only when you create a CAP_BIND_NET_SERVICE

ACE (the parameter specifies a range of port numbers).

Controlling File Access with LIDS

To create a new entry, or ACE, you need to know three things:

The complete pathname of the program that you want to manage (unless you want to restrict all programs).

The complete pathname of the file (or directory) that you want to protect.

The type of access you want to grant (or deny). You can assign four security levels to an object:

WRITE: This level does not protect the object at all; if users hold superuser privileges, they can do whatever they want with the object.

APPEND: This level grants read permission, and lets you add to the object but not delete (or otherwise alter) it. This is the protection level you should assign to all log files. If you grant WRITE protection to a log object, intruders could edit the object to hide their tracks.

READONLY: This level grants read permission, but the object cannot be altered (or deleted).

Use the READONLY level for all system configuration files and programs.

DENY: Objects that are secured at the DENY level are hidden from view. Use DENY to hide password files and then grant exceptions to only those programs that require access.

After you have those three pieces of information, create an ACE with the lidsconf -A command. For example, to protect all files (and subdirectories) in the /etc directory from modification, use this command:

# lidsconf -A -o /etc -j READONLY

In this case, /etc is the object, and because you didn’t include a subject, this ACE will control the type of access granted for all programs. To grant an exception to the default rule, use this command:

# lidsconf -A -s /usr/bin/passwd \ -o /etc/passwd \

-j WRITE

The -s subject parameter defines the subject, and -o object defines the object.

Delete an ACE with lidsconf -D. To delete an ACE, you supply a subject and an object, just like you did when you created the ACE:

# lidsconf -D -s /usr/bin/passwd \ -o /etc/passwd

You must protect a program before you can use it in another ACE. For example, if you want to grant write privileges to the passwd command, you have to protect /usr/bin/passwd first. That makes sense because you don’t want to grant privileges for a command that might be modified by an intruder.

It’s a good practice to protect just about everything first, and then grant exceptions.

For example, to protect Samba configuration files, start out by denying write access for all programs:

#lidsconf -A -o /etc/samba -j READONLY

#lidsconf -A -o /var/samba -j READONLY

Next, grant write access to the Samba daemons (smbd and nmbd). Don’t forget to protect the daemons against modification:

# lidsconf -A -o /usr/sbin -j READONLY

Now you can grant write access to the two Samba executables:

# lidsconf -A -s /usr/sbin/smbd \ -o /var/samba \

-j WRITE

# lidsconf -A -s /usr/sbin/nmbd \ -o /var/samba \

-j WRITE

If you forget to protect a program before you grant privileges for that program, you’ll see an error message such as lidsconf: subject file is not protected.

Hiding Processes with LIDS

Another nifty feature of LIDS is the CAP_HIDDEN capability. CAP_HIDDEN is a pseudo-capability. It’s not really part of a normal Linux kernel but a feature added by LIDS itself. Why would you want to hide

a process? So intruders don’t know that you’re watching them. Protect network sniffers, log file

analyzers, and security monitors with CAP_HIDDEN, and intruders will think they’re all alone on your computer.

When you hide a process, you don’t actually hide the program itself (use DENY to do that); instead, you’re hiding the process from the process list. In other words, you can still see the program if you browse through a directory listing, but if you run the program and then search through the output from a ps command, you won’t find it.

If you’re accustomed to using top to watch what your system is doing, here’s how you can hide the top process from intruders (or anyone else for that matter):

1. Open the file /etc/lids/lids.cap in your favorite text editor.

2. Find the line that says

+29:CAP_HIDDEN

3. Change that line to read

-29:CAP_HIDDEN

Basically, you change the + sign to a – sign.

4. Save your work and close the editor.

This change disables the CAP_HIDDEN capability. (You have to disable a capability before you can grant it to a specific program.)

5. At the command line, disable LIDS for your login session:

# lidsadm -S -- -LIDS SWITCH

enter password:

6. Enter your LIDS password when prompted.

The default LIDS password for the ADIOS UML VMs is 12qwaszx.

When you disable LIDS for a login session, LIDS continues to enforce the security policies for all other uses, but you can bypass LIDS in your login session in order to change the LIDS access control list.

7. Find the program that you want to hide (in this case, top):

#which top /usr/bin/top

8.Grant the CAP_HIDDEN capability to top:

#lidsconf -A -s /usr/bin/top \

-o CAP_HIDDEN \ -j GRANT

9. Tell LIDS to reload its configuration file:

#lidsadm -S -- +RELOAD_CONF

10.And finally, enable LIDS for your login session:

#lidsadm -S -- +LIDS

TABLE 61-1: LIDS CAPABILITIES

Now when you run top, it doesn’t appear in the list of processes. You can’t see it with the ps command. You can’t find it by looking through the /proc directory. You can’t even see it in top! Now you can

spy on other users, er, intruders, without anyone knowing.

Running Down the Privilege List

Table 61-1 lists the superuser capabilities that you can enable and disable with LIDS. If you’re testing a prototype configuration in a UML, start by disabling most of the superuser capabilities and then adding back the privileges you find you need. Copy the access control list (stored in /etc/lids/*) to your main system when you’re happy with the results.

CAP_CHOWN CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH

If disabled, the program cannot change the owner or group owner of any file.

If disabled, the program cannot ignore file access permissions even with superuser privileges.

Disable this capability, and the program cannot ignore file access permissions when reading a file or searching a directory. (This is a little less restrictive than CAP_DAC_OVERRIDE.)

CAP_NET_BIND_SERVICE

CAP_NET_BROADCAST

CAP_NET_ADMIN

CAP_NET_RAW

CAP_IPC_LOCK

CAP_IPC_OWNER

CAP_SYS_MODULE

CAP_SYS_RAWIO

CAP_SYS_CHROOT

TCP port numbers 1–1024 are privileged — only the superuser can create a service that listens for clients on a privileged port. That’s handy because a client knows that if it’s connecting to a privileged port, it’s probably not connecting to a joker that’s set up a private service to impersonate a legitimate service. If you disable CAP_NET_BIND_SERVICE, the superuser cannot create services on privileged ports; you can grant CAP_NET_BIND_SERVICE to selected programs such as the sshd daemon.

Disable this capability, and the superuser can’t broadcast network messages (he or she has to send messages to each computer, one at a time).

If this capability is disabled, the superuser can’t manage network interfaces. By default, LIDS disables this capability and then grants it to selected programs.

If a program can access a network interface in raw mode, it can fabricate network packets in order to fool other computers. Disable CAP_NET_RAW, and the superuser is denied raw access to network devices. By default, LIDS disables this capability and then grants it to selected programs.

If this capability is disabled, the superuser is not allowed to lock shared-memory segments that he or she doesn’t own. This is a rather obscure capability that you can probably ignore without serious consequence.

Normally, a superuser can access any shared memory segment, semaphore, or message queue. If you disable CAP_IPC_OWNER, the superuser can only access interprocess communication objects that he or she owns.

Disable CAP_SYS_MODULE, and the superuser can’t load or unload kernel modules. This is a good capability to disable because if a superuser can load good kernel modules, he or she can also insert pesky modules that can really mess up your system.

If you disable this capability, the superuser doesn’t have raw access to disk drives and can’t poke around in kernel memory. If the superuser has raw access to a disk drive, he or she can easily bypass file system permissions and can even corrupt your data.

Disable CAP_SYS_CHROOT, and the superuser can’t create chroot jails — he or she can’t break out of chroot jails either. By default, LIDS disables CAP_SYS_CHROOT. You have to grant CAP_SYS_CHROOT to the sshd daemon if you want to run an ssh server.

CAP_SYS_PTRACE

CAP_SYS_PACCT

CAP_SYS_ADMIN

The CAP_SYS_PTRACE capability is typically granted to debuggers. It’s a good idea to disable CAP_SYS_PTRACE and then grant it when needed.

Turn off this capability, and the superuser can’t manipulate the process accounting package on your computer (see Technique 21 for more information).

This capability is something of a catch-all for all system administration actions. If you disable this service, the superuser can’t perform administrative tasks like changing the host name, configuring disk quotas, mounting new file systems, or shutting down your computer. By default, LIDS disables this capability and grants it to selected programs (such as mount

and halt).

Save Time By

Using graphical interfaces to get input from your users

Using zenity and the GNOME Toolkit to add graphics to your shell scripts

Using kdialog from KDE to add graphics to your shell scripts

When you think of writing a shell script, you think about the command line. If you need to ask the user a question, you probably echo a string to the terminal window (standard output stream)

and read the reply from the keyboard (the standard input stream). If you want to give feedback to the user, you echo a string to the terminal window. That works, but it’s not very flashy.

Linux offers several graphical toolkits that you can use from within a shell script to display information dialogs. By using the toolkits with your shell scripts, you can graphically

Query your users for passwords with a pop-up dialog.

Use calendars to retrieve important dates from your users.

Display text boxes showing file contents to your users.

Display completion gauges (for file uploads or downloads).

Use checklists and forms to retrieve user information.

Because your users are (probably) used to working in a graphical environment, the dialogs will be friendlier and easier to use. You’ll also have better control of the result set returned to your program — your users can choose their input from the buttons you give them instead of improvising at the command line.

In this technique, we introduce you to using graphical toolkits to share information with your users. Use these kits to make work easier and more attractive for you and your users. The little time it takes to build them into shell scripts is worth the effort.