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

Week 44: Permissions, part 2 -- Who owns what when?

Attackers can gain access to your system through files, directories and devices with higher privileges than necessary that execute on behalf of a privileged task.

Daily if automated, weekly if ad hoc. Daily if your system is an attractive target for intrusion attempts or you have a history of such.

Attackers can gain access to your system through files, directories and devices with higher privileges than necessary that execute on behalf of a privileged task. Most SUID (set user ID) system programs run as SUID root; that is, they become super user when executing. In theory, this isn't a security hole because compiled programs perform only the functions compiled into them. But people have figured out ways of making SUID programs do things they weren't designed to do. Too often, SUID root is used when a group with less privilege would suffice, such as daemon.

Remember that Unix describes UID as the file's owner, GID (group ID) is the file's group. Sometimes unprivileged users need to accomplish tasks that require privileges above theirs, such as the password program, which allows you to change your password and requires modifying the password field in the /etc/passwd file. However, if you had access to this file directly, you could change everyone else's password too. To get around these problems, Unix allows programs to assume another UID or GID when running. A program changing its UID is an SUID program; one that changes group ID is called SGID, and a program can be both at the same time. When a SUID program is run, its effective UID becomes that of the owner of the file, rather than of the user who is running it. Remember from last week that file permissions use a 10-character reference.

Consider the following sample output from running the ls -l command:

-rwxrw-r-- 1 shelley staff 64 May 15 19:01 DailyChecklist.txt

The owner of this plain file, DailyChecklist.txt, is Shelley, and she's a member of the group Staff. The following rights are assigned: Shelley has read, write and execute permissions; Staff has read and write permissions; and all others have read permissions. If the program is SUID or SGID, the output will display an S in the display where the owner or group x is, for example: -rwsrw-r--.

Using the four-digit octal representation of permissions, use the following commands to find out which files have 'setuid' and 'setgid' (especially setuid root files), permissions, respectively:

# find / -perm -2000 -print
# find / -perm -4000 -print

You can look for these SUID and SGID files by creating a daily or weekly cron script and receive the results in an e-mail from the system. You can combine both commands above into one and mail the results:

# find / ( -perm -4000 -o -perm -2000 ) -print | mail -s "setuid and setgid files"

More information
Integrity checkers like Tripwire ( ) can make your job easier. They monitor the permissions and checksums of important files so you can detect whether they have been modified. COPS ( ), by Dan Farmer, is the Computer Oracle and Password System, a system that checks Unix systems for common security problems, like unsafe permissions on key files and directories. Tiger ( ), by Doug Schales of Texas A&M University, is a set of scripts that scan a Unix system looking for security problems in the same fashion as COPS, which was originally developed to provide a check of Unix systems on the A&M campus that users wanted to be accessible off campus.

About the author
Shelley Bard, CISSP, CISM, is a senior security network engineer with Verizon Federal Network Systems (FNS). An information security professional for 17 years, Bard has briefed and written infosecurity assessments and technical reports for the White House and Department of Defense, special interest groups, industry and academia. Please e-mail any comments to

Opinions expressed in this column are those of Shelley Bard and don't necessarily reflect those of Verizon FNS.

This was last published in October 2004

Dig Deeper on Data security technology and strategy

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.