When
Daily if automated; weekly if ad-hoc. Daily if your system is an attractive target for intrusion attempts or you have such a history.
Why
Files, directories and devices that can be modified by any user are known as "world–writable" and are dangerous security holes. Ratcheting down your permissions also protects legitimate users from mistakes.
Strategy
Unix describes file permissions using a 10-character reference. The first indicates the type of file; the next nine characters taken in groups of three show who on your computer can read, write and execute the file. Three classes of permissions show who can modify it -- owner, group and other. For example, -rwxr-x--- is a plain file whose owner has read, write and execute privileges, those in the group can read and execute it, and no access is granted to anyone else.
Vulnerable files that should not be world–writable include: .login; .rhosts; dev/drum; /dev/mem; /dev/kmem (nor world-readable either); /etc/passwd and /etc/group (owner root and mode 644 recommended); and device files for hard disk partitions.
If you have a server that exports file systems containing system programs like in the /bin and /usr/bin directory, you might export them Read Only, thus rendering the client unable to modify files in that directory. To export a file system Read Only, you must specify the Read Only option in the /etc/export or /etc/dfs/dfstab file on the server.
In general, files beginning with a period should not be world- or group-writable. Home directories and their associated files should be writable only by the owner. Many files should only be readable by the owner as well, hindering an intruder searching for other attack avenues. Using the 4-digit octal representation of permissions, this would be 0600.
Before editing existing file privileges, be sure to back up data, and/or create a restore point for your system. To find either group or world writable files beginning with a period in the Example file system, execute the following:
# find /example –perm -2 –o –perm -20 –name .* -ls
You can pipe the results to a file to keep a report. To do this regularly, put it in a cron script, and mail the results to your admin account. For a list of all setuid root files, for example, execute:
# find / -user root –perm -4000 –print | mail –s "setuid root files" myname@myorganization.com
To find out what permissions a Windows user or group has, use Effective Permissions: To view effective permissions on files and folders (indicated by a check mark):
1. Open Windows Explorer and locate the file or folder.
2. Right-click on it, click Properties and click the Security tab.
3. Click Advanced, then the Effective Permissions tab.
4. Click the Select button.
5. In Name, enter the name of a user or group and click OK. The selected check boxes indicate the effective permissions of the user/group for that file/folder.
Information displayed here is read-only. It takes the permissions in effect from group membership into account, as well as any permissions inherited from the parent object, and will look up all domain and local groups the user or group is a member of. This excludes these security identifiers: anonymous logon, authenticated users, batch, creator group, creator owner, dialup, enterprise domain controllers, interactive, network, proxy, restricted, self, service, system and terminal server user). Note the "everyone group" will always be included as long as the selected user or group is not a member of the anonymous logon group.
More information
See the Unix man pages for more on Unix permissions and the find command. More information on Windows permissions and access control lists and entries; a good overview on Windows permissions.
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.
Opinions expressed in this column are those of Shelley Bard and don't necessarily reflect those of Verizon FNS.
