Problem solve Get help with specific problems with your technologies, process and projects.

Minimizing the risks from freely available software

Minimizing the risks from freely available software
By Aeleen Frisch

Downloading software can often make administrators' jobs easier. But might this unknown software pose a security risk. In this tip from Aeleen Frisch's Essential System Administration, Aeleen shares her procedures for testing strange software.

There is a lot of great software available across the Internet, including both programs that will help you do your job more effectively and ones that are just fun to have and use. If approached with a reasonable amount of caution and common sense, such software need not compromise system security, but you do have to be careful.

I follow the following procedure every time I acquire a program from an Internet or another anonymous source -- in other words, anytime I have to assume that some cracker has messed with an otherwise benign program.

* Examine and test the program as an unprivileged user. Don't try it as root first, and make sure that the account has no extra privileges if your system supports them in some fashion (as is true under IRIX, AIX, SCO Unix and Digital Unix).

* Always build the program from source code. Don't even consider running precompiled binaries.

* Examine the archive before unpacking it. Be suspicious -- or at least annoyed -- at any absolute pathnames among the files in the archive.

* Unpack the archive into a secure area where mistakes can be easily cleaned up. Use a special test system if you have one.

* Examine the file types (using the file command) of the component files. Be very suspicious of any binary files. A reputable program will enable you to regenerate any needed binary data files via a starter program for which the source code is provided. Carefully examine any file which seems odd (for example, an editor initialization file).

* Look over the source code to as great extent as you can, trying to get a feel for the program's general structure. (This will prove helpful when you have to fix bugs.) Make a note of any inadvisable system calls, undocumented options (compare with the manual pages) and hard coded file names. (Another, more devious form of a Trojan horse consists of a call to an external object, so that the source for the program itself appears relatively innocuous.)

* Look over the makefile and perform any needed configuration or customization. Then use make -n to preview the build process, and make sure that all files will be created in the local directory. If everything looks fine, then build the program.

* Examine the objects created by the build process with the strings command, which displays all ASCII character strings present within the binary file. There should be no surprises among any of the system objects in finds listed there.

* Test the program as extensively as possible, using all local files. This is possible even for programs that access system data files like /etc/passwd. Modify the makefile or the source code itself so that it works on a passwd file in the local directory and test that before you let it touch the real file.

* When you are sure that you want to install the program, preview the process first (often done by running make -n install), and note where executables and other files will be placed as well as their ownerships and permissions. Be suspicious of any installed files other than executables and data files that you have built and manual pages.

* Test the program in its installed form, watching for unexpected side effects. One way to detect them is to run the program on an idle system in this way:

$ touch /tmp/xxx

$ new_program ?

$ find / -newer /tmp/xxx ?print

The final command will locate any files modified by the program (assuming that you really do have the system to yourself).

* If there are any SUID or SGID commands present, see if they use the minimum privilege required to perform their function.

Is this procedure more than a little paranoid? Absolutely. Will it take significantly more time than just running make and hoping for the best? Absolutely. Is it really necessary? You'll have to decide that one for yourself. (It depends on how much you like reinstalling the operating system.)

Related book

Essential System Administration, Second Edition
Author : Aeleen Frisch
Publisher : O'Reilly & Associates
ISBN/CODE : 1565921275
Cover Type : Soft Cover
Pages : 788
Published : Sept. 1995
Essential System Administration takes an in-depth look at the fundamentals of UNIX system administration in a real-world, heterogeneous environment. Whether you are a beginner or an experienced administrator, you'll quickly be able to apply its principles and advice to your everyday problems.

This was last published in February 2001

Dig Deeper on Productivity apps and messaging security

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.