UNIX Filesystem Countermeasures

Here are some things you can do to minimize your filesystem exposures.

· Give clear direction in your security policy about the need to protect the organization's data. Classify information by sensitivity and define what access controls are required. Give examples.

· Set the TMPDIR environment variable to a private, per-user temporary directory. Well-behaved programs check TMPDIR before using /tmp.

· Audit your shell scripts and change all references to publicly writable directories to your own tmp directory. For bonus points, create unique filenames without relying on the time, date, or process ID (or a weak pseudo-random number generator).

· Educate users about file permissions and the effect of the umask. In sensitive environments, have your users sign a usage policy that includes good stewardship of information.

· Ask users about their information-sharing needs. Create additional UNIX groups as necessary and enroll users as appropriate to support data sharing at a more granular level. The group's mechanism can be used very creatively—think long term and design a flexible group access model.

· Make sure that the system-wide umask is set to 027 in the system shell start-up files as a minimum.

· Modify system startup files to set the umask to 027.

· Create a cron job to check user start-up scripts for inappropriate umask settings.

· Audit /tmp and other shared directories on your servers now. Perform spot checks on /tmp. Persistent offenders should be warned that they are in breach of policy. If the warnings are not heeded and the information is sensitive, consider e-mailing a summary of interesting finds to management.

· Disable core file creation (not to be confused with kernel crash dumps) via the ulimit command. Modern UNIX kernels will refuse to dump core when a set-uid program crashes because this might reveal sensitive information. However, privileged system daemons and application processes might dump core resulting in chunks of sensitive system files being written to world readable core file. Validate your fix by sending a QUIT signal to a expendable network service and check that it doesn't produce a core dump in its current working directory. (/proc or lsof can help find that out.)

· Monitor /tmp for predictable filenames using a tool such as L0pht's tmpwatch.

· Make sure named pipes are included in your file permission checks! These are used for Inter Process Communication (IPC), so that lax permissions will allow an attacker to interact with processes in ways you don't want.

· Prevent file giveaways by setting CHOWN_RESTRICTED to true in the kernel configuration file.

· Consider using extended ACLs (where supported) via the getfacl and setfacl commands (Solaris). These extend the access information stored in the inode. They can be used to give a user access to a file or directory even if that user is not in the owning group or is not the file owner, and the file permissions deny access by "Other." But ACLs can be a real pain to administrate. Personally, I recommend that you design a good group model and only use extended ACLs when you really need to.