Section 13.5. Letting Others Do Privileged Operations

13.5. Letting Others Do Privileged Operations

Often we are asked to create a way for normal users to do things typically permitted only by an administrative account such as root. This can be quite dangerous and should be done with great care.

In Unix/Linux, there is a program called sudo that lets system administrators give a person the ability to run a command as another user. It is very restrictive, requiring the system administrator to configure it to specify exactly which user(s) can run which command(s) as which other user.

For example, you can configure it to permit a particular person to run a command as root. You can rely on sudo to make sure that only the people you specify have the ability to run this command as root, but it is important that the program check the parameters to make sure that privileged users are able to overstep their bounds.

Any kind of system that lets "normal" people do "privileged" operations is a risky system to build. Computer security history is fraught with well-meaning programmers accidentally creating security holes that let people run any command as root or administrator.

If you aren't sure what you are doing, research security books and FAQs for advice.

For example, if it requires root to run the Unix mount command to access a CD-ROM. It is a bad idea to configure sudo so that the person can run the mount command as root with any parameters. He could crash the system or break security. It is much better if you configure sudo to let the person run a new command (say, mountcd) as root. This command will make sure that he has specified the particular CD-ROM drives that the user is permitted to mount (with a logical default), and mounts that drive. You also want to give him an (unmountcd) command.

I like to build three layers when I automate something for other people:

• Layer 1. A program that does the basic task.

• Layer 2. A program that the user will run, with sudo, that collects her input, validates it, makes sure she isn't trying to do anything fishy, and then calls the first program.

• Layer 3. A more user-friendly way to access these previous layers, such as a web interface or menu program.

For example, at one company, we had a process for pushing a new version of the company web site to the world. It involved three different web servers (actually they were virtual servers on two different machines, but those details aren't important).

www-draft.example.com

The next release of our web site was developed here.

www-qa.example.com

The draft site would be copied here for QA to check over. Once the copy was made, the files were immediately made read-only. If QA approved this site, we needed to be able to verify that these exact bits were copied to the live site.

www.example.com

This was the live site that external people would see.

The web designers would ask the system administrators to copy their draft to www-qa.example.com. When the QA group approved the site, they would tell the system administrators to make the site go live.

Each of these two functions was automated:

readyforqa

Copied the draft site to the QA site.

golive

Copied the QA site to the live site.

Marketing demanded a way to make emergency updates when the QA department wasn't available. We created this command:

emergency-draft-to-live

Copied the draft site directly to the live site after asking "Are you sure?" a few times.

These three scripts comprised Layer 2, which I mentioned earlier. Layer 1 was a script that did the actual copying of one site's data to another site, making a backup along the way, and setting files to read-only (changing the ownership of the files, too). Layer 1 had to be done as root because it was changing ownership of files and accessing machines via secured channels.

sudo was programmed as described in Table 13-1.

Table 13-1. Web update permission table

	Web developers	QA	Marketing
Readyforqa	X		X
Golive		X
Emergency-draft-to-live			X

We actually went through the effort of having management sign off on this chart, with real signatures, to make sure they understood that they were agreeing to what they thought they were agreeing to. The political process to get this approved was the difficult part. It took weeks. Presenting the information to management in the chart form made it a lot easier for a decision to be made. They could understand and update the chart themselves until they were happy with it. Translating the final chart into a sudo configuration file was the easy part.

Per Layer 3, we decided to make an easier way for people to access these commands. We considered a web interface, but, in this case, the users were satisfied with a menu program that presented them with a list of options that ran the appropriate command.

The menu ran without any additional privileges (i.e., not under sudo), but called the Layer 2 programs using sudo as needed .