Changing the setuid or setgid Bit

441

Deciding to Turn Off setuid or setgid

The big secret to creating a more secure system is to figure out what programs don’t need the setuid bit turned on and then turn the bit off for those programs. If you see a setuid or setgid program that you don’t recognize, Google for it on the Web. If in doubt, turn off the setuid or setgid bit (see the next section for details) and see if anything breaks.

Turning off the wrong setuid bit or setgid bit can lock you out of your system. Know your programs and permissions, and keep a terminal window open with superuser privileges until you’ve tested the program with your regular login.

Use sudo to distribute extra privileges to the users that need them. It’s a lot safer than handing out unlimited access to everyone. See Technique 31 for some great ideas about using sudo.

Changing the setuid or setgid Bit

You may want to disable the setuid or setgid bits on some of the programs that aren’t used often or anything that you can’t really identify.

Try to find out what a program is before you disable its setuid or setgid bit. If the program looks questionable and leaves a door open, it may be a security risk.

You can tell that a program has the setuid (or setgid) bit turned on by looking at the output from an ls -l command. If you see an s in the fourth (from the left)

permission column, you’re looking at a setuid program. If you see an s in the seventh permission column, you’re looking at a setgid program.

If you look at a normal Linux program (that is, a program that is not setuid or setgid), you won’t see any s:

-rwxrwxr--

1 fred fred

1001

Dec 13 18:50 myprogram

To turn on the setuid bit, use the following command:

$ chmod u+s myprogram

ls -l then shows this:

-rwsrwxr--	1 fred fred	1001 Dec
13 18:50 myprogram

You have to be the file’s owner (or have superuser privileges) to change the setuid or setgid bits.

To turn on the setgid bit, use the following command:

$ chmod g+s myprogram

ls -l then shows this:

-rwsrwsr--	1 fred fred	1001 Dec
13 18:50 myprogram

A program that has the setgid bit turned on assigns the file’s group ID to the process.

To turn the bits back off again, use these commands:

$ chmod u-s myprogram $ chmod g-s myprogram

442 Technique 57: Search and Destroy setuid and setgid Programs

If you see an uppercase S instead of a lowercase s, the setuid (or setgid) bit is turned on, but the execute bit is turned off. That’s usually a nonsensical combination.

A directory with setuid or setgid privileges turned on forces all the files and subdirectories within them to be owned by the directory owner or group instead of the user creating the file. A setuid (or setgid) directory is not a security risk in the same way that a setuid/ setgid program is. You don’t have to disable setuid/setgid directories to make your system more secure.

58	Quarantining
	Suspicious Programs
Technique	with UML

Save Time By

Using UML and LIDS to keep potentially vulnerable programs in a safe place

Keeping hazardous programs from touching your configuration files

Resolving LIDS conflicts so servers can reach out from inside a jail

You can put the most secure server behind a firewall, allow only secured logins, and limit administrative access, but somebody’s gonna find a way to break in. You can only do so much to keep peo-

ple out of your server and still keep it functional. The only truly secure system is one that’s completely isolated from the outside world, which makes it pretty hard to offer network services (like e-mail and Web pages). Instead of taking your servers completely offline, create a sacrificial server that you can afford to lose if someone does manage to break in. Of course, most of us can’t afford to throw out a compromised system and replace it with new hardware. Instead, you can use UML (User Mode Linux) to create a virtual server.

Running a server from within a UML virtual machine isolates the server from the rest of your system. As far as your server knows, the rest of your Linux machine doesn’t exist, so to the eyes of an invading hacker, your real computer doesn’t exist either.

The open-source software movement has a lot to offer, but even highquality programs sometimes harbor unintentional vulnerabilities. Even if you get your software from long-established and trusted sources, software often contains back doors and Trojan horses. Confining those programs can protect the rest of your system from any viruses, Trojan horses, or other security breaches that they might include.

In Technique 15, we show you how to install User Mode Linux; be sure to review that technique before you go much further. In this technique, we show you how to use UML to create a defensive boundary of protection between vulnerable software and your system. UML can save you from having to repair damage to your system, whether accidental or intentional.

If you’ve searched around on the Web for information about creating jails, you’ve probably seen references to chroot jails. chroot jails are notoriously difficult to create and offer limited protection. In this technique, we show you how to build a whole penitentiary with UML instead. UML jails are easier to build and manage, and provide a stronger line of defense than chroot jails.

444 Technique 58: Quarantining Suspicious Programs with UML

Who Belongs in Jail?

In the real world, troublemakers belong in jail. In the world of computer software, potentially bad or vulnerable programs belong in jail. The programs and data you’re trying to protect remain outside the jail, beyond the reach of intruders. A UML jail acts as a security barrier protecting the sensitive data and programs on your system from hackers, Trojan horses, and viruses that might come in by way of a back door — through servers or through software that might be a bit suspicious.

Good candidates for confinement in a UML jail include the following:

All kinds of servers, including mail, data, FTP, and Web servers

Downloaded but potentially vulnerable software

Technique 18 shows you how to check the signature key on downloaded software with rpm -V. Checking the signature ensures that the software came from a reliable source (or at least from the same person who claims to have built the software). Check it out — protecting your system is worth the time.

The files that belong outside the jail are the files that need protecting:

Password files

Configuration files

Data files

Anything really important

By putting these files outside the jail, you protect them from the jailed programs and from anyone who might break into the programs in the jail. With a UML jail, you create a defensive barrier to protect the files outside the jail from both the programs in the jail, and the users with access to those programs.

In the sections that follow, we explain how to set up a UML jail and install a simple Apache server in the jail. It’s a great way to use a UML jail, and you can have a secure server up and running in no time.

Using UML to Jail Programs

UML is a jail in and of itself — an isolated environment where you can run programs without the programs having easy access to the rest of your system files. ADIOS installs four different UML configurations in your KDE menu: LIDS Off, LIDS On, SELinux Permissive, and SELinux Enforcing. LIDS and SELinux are hardening tools that further clamp down on vulnerabilities in a Linux system (in this case, a UML VM).

Check out Technique 15 for quick installation instructions for UML.

We tell you more about LIDS in Technique 61, but for now, here’s a quick summary: LIDS takes away the superhuman powers of the superuser. When you’re running in LIDS On mode, LIDS doles out superuser privileges to specific programs (hopefully programs that you trust) rather than give every possible privilege to someone who knows (or absconds with) your root password. The big advantage to LIDS is that it protects your system (or your jail) against a hacker who somehow manages to impersonate user root.

With a few easy steps, you can isolate your host system, protecting it from adventurous hackers, while still offering network services to the outside world. If anyone does manage to compromise your server, that person has access only to the files and programs that you’ve installed in the jail. If you keep a trusted backup of your UML jail, recovering from an intrusion is trivial.

To create a UML jail, follow these steps:

Using UML to Jail Programs 445

1. Open the main KDE menu and choose User Mode Linux LIDS On.

2. When the happy penguin appears, log in as user root (the password is 12qwaszx) (see Figure 58-1).

Be sure that the /tmp/uml/jail directory contains no symbolic links to the rest of the host system. Use the ls -l command to list the directory contents; if any of the permissions begin with an l, they’re symbolic links and should be deleted.

• Figure 58-1: The UML login screen.

When you’re inside a UML VM, you have complete access to the host file system through the directory /mnt/host. If you peek at /mnt/host, you’ll see subdirectories like /mnt/host/bin,

/mnt/host/etc, /mnt/host/usr, and /mnt/host/ home. Those directories correspond to the /bin, /etc, /usr, and /home directories on the host computer.

That’s not a good arrangement when you’re trying to block off access to those files.

3. To close that security hole, find a directory that you do want to expose to the jail (or better yet, just create an empty directory) and grant the VM access to that directory instead.

For example, create a staging area like this:

# mkdir /tmp/uml/jail

Run that command in the host, not in the

UML VM.

Any files that you put into /tmp/uml/jail will appear inside the VM in the directory /mnt/host.

After you create the jail and add files to it, adjust the script that boots your VM:

1. Open the file /usr/bin/uml with your favorite editor.

2. Find the line (near the top of the file) that says

LIDS_KERNEL=uml_linux_lids

3. Change the line to read

LIDS_KERNEL=”uml_linux_lids

hostfs=/tmp/uml/jail”

Don’t forget the quotes, or your UML VM won’t boot.

4. Find the line that says

SELINUX_KERNEL=uml_linux_selinux

This line should be just below the line in Step 2.

5. Change the line to read

SELINUX_KERNEL=”uml_linux_selinux

hostfs=/tmp/uml/jail”

6. Save your work and close the editor.

Now you can easily copy files between the host and the VM to populate your UML jail. You can copy files into (or out of) /tmp/uml/jail from your host system. Inside the VM, copy files into (or out of) /mnt/host. It doesn’t get any quicker or easier

than that.

446 Technique 58: Quarantining Suspicious Programs with UML

Actually, it does get a bit quicker. Open a terminal window and grant yourself superuser privileges. Start two Konqueror (or Nautilus) sessions by typing in konqueror (or nautilus) at the command line. With one browser window open to /tmp/uml/jail, and the other browsing for the programs or files you want to add, you can populate your UML jail in no time!

When you need to add software to your new UML jail, you can copy program files in at the command line, or use your browser. Either way, you’ll find it a snap to populate the Apache server you set up later in this technique.

Changing the Default

Password to the Jail

The UML VM comes with a simple and easy-to- remember default password that works as both the root login and the LIDS password. That might be handy at first, but you should change it quick: It’s easy for everyone to remember, even the bad guys.

To change the LIDS password, follow these steps:

1. Open the main KDE menu and choose User Mode Linux LIDS Off.

2. Log in using the default password.

The default password is 12qwaszx.

3. Enter the following command:

# lidsconf -P

4.When prompted, enter a new password and then reenter the new password.

5.Stop the UML VM with the halt command.

6. Start UML again with LIDS on. Open the main KDE menu and choose User Mode Linux

LIDS On.

That’s all there is to it.

To change the root password, log in to the UML VM as root, and use the passwd command, just like you normally would.

Installing New Software and

Resolving Conflicts

After you set up the jail and change the default password, your new UML jail is ready for software. Remember, any software you need to run (and manage) inside your new jail must be installed in the jail. You can’t reach into the outside world to borrow utilities anymore.

One thing you might want to install into your UML jail is Apache (or, more precisely, the Apache httpd Web server). The Apache RPM package is included in most Linux distributions.

The following steps explain how to install the Apache RPM in the UML jail, but you can modify these steps for any program:

1. From your host machine, copy the RPM package from the distribution CD to the UML VM:

#cp httpd-2.0.47-10.i386.rpm /tmp/uml/jail

2.Move into the UML jail and make your session a LIDS off session with the following command:

#lidsadm -S -- -LIDS

This loosens restrictions on the superuser account while you do system maintenance.

Installing New Software and Resolving Conflicts 447

3. Move to the directory containing the RPM package:

#cd /mnt/host

4.Install the RPM package with the following command:

#rpm -Uvh httpd-2.0.47-10.i386.rpm

5.Start the httpd daemon by entering this command:

#service httpd start

When you start the httpd daemon, you may get a series of LIDS violation reports. You need to resolve any conflicts with the LIDS security issues before your server can run.

You are likely to encounter the following errors:

Violated CAP_NET_BIND_SERVICE

Trying to bind port 443

Attempt to unlink /etc/httpd/logs

To resolve these errors, follow these steps:

1. Give yourself a LIDS off session with the following command:

#lidsadm -S -- -LIDS

2.Resolve the first two error messages with these commands:

#lidsconf -A -s /usr/sbin/httpd -o

CAP_NET_BIND_SERVICE 80-80 -j GRANT

# lidsconf -A -s /usr/sbin/httpd -o CAP_NET_BIND_SERVICE 443-443 -j GRANT

You’ve just granted httpd the right to service ports 80 and 443.

3. Resolve the third error message with the following command:

#lidsconf -A -s /usr/sbin/httpd -o /etc/httpd/logs -j WRITE

You’ve just given Apache the right to modify its own logs.

4. Reload the LIDS configuration database:

#lidsadm -S -- +RELOAD_CONF

5.Restart the Web server daemon:

#service httpd start

When httpd starts, it tells you the IP address of the Apache session. Make a note of this IP address because you’ll need it in a moment.

6. Return to a LIDS on session with the following command:

# lidsadm -S -- +LIDS

7.Enter the LIDS password, and you’re running the Apache server in a secure environment.

8.To verify that Apache is running, open a browser on the host machine and enter the IP address of the service in the Location field:

http://192.168.202.1

The Apache test screen opens, confirming the server is running. The service isn’t configured yet — you find out how to do that in Technique 42. The service is secure though.

Use the same technique to install other RPM packages. You may have different LIDS conflicts to resolve — see Technique 61 for more information about LIDS.

To make a quick backup of your UML VM, just back up the cow file in /tmp/uml. See Technique 15 for more information about cow files.

59 Troubleshooting

Persnickety

Technique Programs

Save Time By

Using lsof to find open files

Using strace to track down trouble spots

Watching your programs with ltrace

Recording memory usage errors with valgrind

Linux is a fairly mature operating system. In the early days of Linux development, users found problems everywhere they turned. That’s not to say that Linux is any different from other operating systems;

it takes time to iron out the wrinkles in any program. In fact, the “superbuggy” stage of Linux development was remarkably short, and you can now run a Linux system for months at a time without encountering a bug. Often, the problems that you run into aren’t really bugs — they’re configuration problems.

Tracking down the cause of a problem in a program (whether it’s a bug or a configuration issue) can be tricky, but Linux has a number of tools that can help.

The lsof command shows you information about open files, open devices, and open network connections. Ever tried to unmount a CD and found that some process has a file open on the CD drive? lsof is the answer. Need to create a clean backup of a complex database? Use lsof to make sure that your database is not in use.

We also introduce you to two related tools:

strace reaches inside a program and shows you a complete list of all the system calls (calls into the Linux kernel) made by that program. You can browse through the log produced by strace to find which files are opened by the program causing problems. Configuration problems often appear because a file is missing or protected too strongly. If you have a program that’s reading configuration information from a mysterious location, use strace to find the hidden files.

ltrace is similar to strace. While strace logs all system calls, ltrace displays calls made to shared libraries. To a programmer, Linux is more than just a kernel. It’s also a huge collection of code libraries, written by others, but designed to share among many different programs. Shared libraries take care of operations like memory allocation, encryption, compression, GUI interaction — just about everything that doesn’t happen in the kernel. Watching the library calls made by a program can help pin down a configuration error whether the problem trips up the kernel (strace) or a shared library (ltrace).