Hack 56 Protect Files with Flags

Ever feel limited when tightening up Unix permissions? Really, there's only so much you can do with r, w, x, s, and t.

When you consider the abilities of the superuser account, traditional Unix permissions become moot. That's not very comforting if you're a regular user wishing to protect your own files or an administrator trying to protect the files on a network server from a rootkit.

Fortunately, the BSDs support a set of extended permissions known as flags. Depending upon your securelevel, these flags may prevent even the superuser from changing the affected file and its flags.

6.4.1 Preventing File Changes

Let's start by seeing what flags are available. Figure 6-1 summarizes the flags, their meanings, and their usual usage.

Table 6-1. Extended permissions flags

Flag name	Meaning	Usage
arch	archive	Forces or prevents a backup
nodump	nodump	Excludes files from a dump
sappnd	system append	Applies to logs
schg	system immutable	Applies to binaries and /etc
sunlnk	system undeletable	Applies to binaries and /etc
uappnd	user append-only	Prevents changes to existing data
uchg	user immutable	Prevents any type of changes
uunlnk	user undeletable	Prevents deletion or rename

Any user can use any flag that starts with u to protect her own files. Let's say you have an important file that you don't want to change inadvertently. That's a candidate for the uchg flag. To turn that flag on, use the chflags (change flags) command:

% chflags uchg important_file % ls -lo important_file -rw-r--r-- 1 dru wheel uchg 14 Dec  1 11:13 important_file

Use ls -lo to view a file's flags. (I tend to think o was the only letter left. Perhaps a mnemonic would be "Hello, this is why I can't modify that file!" Perhaps not.) Let's see exactly how immutable this file is now. I'll start by opening the file in vi, adding a line, and trying to save my changes:

Read-only file, not written; use ! to override.

Okay, I'll use wq! instead:

Error: important_file: Operation not permitted.

Looks like I can no longer make changes to my own file. I'll receive the same results even if I try as the superuser.

Next, I'll try to use echo to add some lines to that file:

% echo "test string" >> important_file important_file: Operation not permitted.

Finally, I'll try moving, deleting, and copying that file:

% mv important_file test mv: rename important_file to test: Operation not permitted % rm important_file override rw-r--r--  dru/wheel uchg for important_file? y rm: important_file: Operation not permitted % cp important_file test %

Notice an important difference between the mv and rm commands and the cp command. Since mv and rm require a change to the original file itself, they are prevented by that unchangeable flag. However, the cp command doesn't try to change the original file; it simply creates a new file with the same contents. However, if you try ls -lo on that new file, the uchg flag will not be set. This is because new files inherit permissions and flags from the parent directory. (Okay, that's not the whole story. See man umask for more gory details.)

6.4.2 Watch Your Directories

What do you think will happen if you place all of your important files in a directory and recursively set uchg on that directory?

% mkdir important_stuff % cp resume important_stuff/ % chflags -R important_stuff/ % ls -lo important_stuff/ drwxr-xr-x   2 dru  wheel  uchg     512 Dec  1 11:23 ./ drwxr-xr-x  34 dru  wheel  -       3072 Dec  1 11:36 ../ -rw-r--r--   1 dru  wheel  uchg      14 Dec  1 11:13 resume

So far so good. That file inherited the uchg flag from the directory, so it is now protected from changes. What if I try to add a new file to that directory?

% cp coverletter important_stuff cp: important_stuff/coverletter: Operation not permitted

Because the directory itself is not allowed to change, I can't add or remove any files from the directory. If that's what you want, great. If not, keep that in mind when playing with directory flags.

What if you change your mind and really do want to change a file? If you own the file, you can unset the flag by repeating the chflags command with the no word. For example:

% chflags nouchg resume

will allow me to make edits to my résumé. However, I won't be able to delete it from that protected directory unless I also use the nouchg flag on the important_stuff directory.

6.4.3 Preventing Some Changes and Allowing Others

Sometimes, the uchg flag is a bit too drastic. For example, if you want to be able to edit a file but not inadvertently delete that file, use this flag instead:

% chflags uunlnk thesis %

I can now edit that file to my heart's content. However, if I try to move or delete that file, I'll receive those Operation not permitted error messages again.

The uappnd flag is more interesting. It allows you to append changes to a file but prevents you from modifying the existing contents. This might be useful for a blog:

% chflags uappnd myblog %

Then again, it might not. echoing comments to the end of the file works nicely. However, opening it in an editor does not. Note that this flag also prevents you from moving or deleting the file.

6.4.4 Log Protection

Let's move on to the rest of the flags, which can be managed only by the superuser. sappnd, schg, and sunlnk work exactly the same as their u equivalents. So, think s for superuser and u for user.

The append flag was a bit weird for a regular user, but it is ideal for protecting the system logs. One of the first things an intruder will do after breaking into a system is to cover up his tracks by changing or deleting logs. This command will thwart those attempts:

# chflags -R sappnd /var/log

Now is a good time to mention a security truth: security is a myth. In reality, security is a process of making things more inconvenient in the hopes that a miscreant will go elsewhere. Remember, though, that inconvenience doesn't just affect the bad guys; it also affects you.

That command seems ideal because it allows logs to be appended to but not modified or deleted. That's great if you live in the world of unlimited disk space. Of course, it also just broke newsyslog, and you've just delegated yourself the joys of manual log rotation.

There's one other thing you need to consider when you start playing with the superuser flags. If your securelevel is set to 0 or -1, the superuser can unset any flag by adding no to it. If your attacker has heard of flags before and has managed to gain access to the superuser account, all of your flag setting was for naught.

Having said that, suppose you're hardening a server and want to protect the logs. Your securelevel is set at 1 or higher, and you plan on using that previous chflags command. Since you're now responsible for log rotation, you might as well start by taking stock of the contents of /var/log before turning on that sappnd flag. Remove any unnecessary logs now, before setting the flag.

Next, edit /etc/crontab and comment the newsyslog line so it looks like this:

# Rotate log files every hour, if necessary. #0        *        *        *        *        root        newsyslog

Comment out any lines in /etc/syslog.conf that refer to logs you removed.

You should also consider using something like the following script to warn you if a partition is filling up:

#!usr/local/bin/bash # checkfreespace.sh # check that a device has sufficient free space # thanks to David Lents and Arnold Robbins for awk/gawk/nawk suggestions # set the following variables as necessary  PARTITION="/var/log" THRESHOLD="80" USED=$(     eval "df | awk -- '\$6 =  = ENVIRON[\"PARTITION\"]         { printf( \"%0.d\", \$5 ) }'" ); if [ "$USED" -ge $THRESHOLD ] then   echo "Used space of $USED above $THRESHOLD on $PARTITION" else   # disable this if running through cron   echo "Enough free space" fi

If you schedule this program through cron, it will mail any output to the user owning the cron job. Edit the two variables at the top of the script to change the partition to scan and the threshold above which the script will warn. With the variables set as shown, the script will warn if /var/log is more than 80% full.

Remember, once you disable newsyslog, it becomes your responsibility to monitor disk space in /var/log. You won't be able to compress or delete log files unless the superuser temporarily unsets the sappnd flag. This can be a real pain if your securelevel is 1 or higher, as the system first has to be dropped down to single-user mode. This usually isn't an option on busy systems as it will disconnect all current connections. Carefully consider the size of /var/log and how often the system realistically can be put into single-user mode before setting this flag.

6.4.5 Protecting Binaries

When a system is compromised, the attacker may install a rootkit that will try to change your system's binaries. For example, it might replace ps with a version that doesn't display the rootkit's processes. Or, it might replace a commonly used utility with another program that executes something nastier than expected.

[Hack #58] shows how to create your own file integrity checking program that will alert you if any of your binaries or other important files are changed. An additional layer of protection is to use chflags to prevent those files from being changed in the first place. Usually, the schg flag is used to prevent any modifications. Useful candidates for this flag are:

• /usr/bin, which contains user programs

• /usr/sbin, which contains system programs

• /etc, which contains system configurations

Again, evaluate your particular scenario before implementing this flag. The protection provided by this flag usually far outweighs the inconvenience. The only time the contents of /usr/bin or /usr/sbin should change is when you upgrade the operating system or rebuild your world. Doing that requires a reboot anyway, so dropping to single-user mode to unset schg shouldn't be a problem.

How often do you change your configuration files in /etc? If you typically configure a system only when it is installed and rarely make changes afterward, protect your configurations with schg. However, keep in mind that a rare configuration change may require you to drop all connections in order to implement it. Also, if you need to add more users to your system, remember to remove that flag from /etc/passwd, /etc/master.passwd, and /etc/group first.

Things are a bit more problematic for a system running installed applications. Most ports install their binaries into /usr/local/bin or /usr/X11R6/bin. If you set the schg flag on those directories, you won't be able to patch or upgrade those binaries unless you temporarily unset the flag. You'll have to balance your need to keep your server up and running with the protection you gain from the schg flag and how often you have to patch a particular binary.

6.4.6 Controlling Backups

The last two flags, arch and nodump, affect backups. The superuser can ensure a particular file or directory will always be backed up, regardless of whether the contents have been altered, by setting the arch flag.

Similarly, when using dump to back up an entire filesystem, the superuser can specify which portions of that filesystem will not be included by setting the nodump flag.

6.4.7 See Also

• man securelevel

• man -a chflags (to view all manpages that match chflags, not just the first one)

• man newsyslog

• [Hack #58]