File Flags

UNIX file system permissions are standard across various versions of UNIX, but OpenBSD extends the permissions scheme with file flags. These flags work with permissions to enhance your systems' or users' security by changing the way the file can be accessed. File flags can make a file unchangeable or make it so that existing data cannot be removed and the file can only be added to. File flags work only in combination with securelevels; however, the two systems are interrelated, and you must understand both parts before implementing them.

Viewing a File's Flags

You can see any flags set on a file with "ls -lo:"

 # ls -lo test -rw-r--r--  1 mwlucas  mwlucas  1 uchg 0 Dec  3 13:42 test # 

This file has the 1 "uchg," or user-immutable, flag set. In comparison, if a file has no flags set, ls -lo will only show a dash in the space where the flag is displayed.

 # ls -lo test -rw-r--r--  1 mwlucas  mwlucas  -  0 Dec  3 13:42 test # 

An out-of-the-box OpenBSD system doesn't have any files marked by flags. You can certainly mark anything that you want, however.

Flag Types

Here are the most commonly used file flags and brief descriptions of how you might use them. There are a few other flags, but their use is rare; see chflags(1) for a complete list.

sappnd

The system-level append-only flag can only be set or removed by root. Files with this flag can be added to but cannot be removed or otherwise edited, a particularly useful feature for log files. Setting sappnd on a .history file can be interesting in the event of a system compromise. A popular script kiddie trick is to remove .history or to link it to /dev/null so that the sysadmin cannot see what was done, but sappnd prevents this tactic from working without changing any UNIX file system permissions on the .history file itself. It's almost funny to watch the record of someone trying to remove a sappnd file — you can almost see the intruder's frustration grow as he tries more and more outrageous things to make the file disappear. (Admittedly, no amount of entertainment is sufficient compensation for having your system broken into!) This flag cannot be removed when the system is running at securelevel 1 or higher.

schg

The system-level immutable flag can only be set or removed by root. Files with this flag set cannot be changed in any way: not edited, not moved, and not replaced. Basically, the kernel will prevent all attempts to touch this file in any way. This flag cannot be removed when the system is running at securelevel 1 or greater.

uappnd

Only the file owner or root can set the user append-only flag. Like the system append-only flag, sappnd, a file with this flag set can be added to but not otherwise edited or removed. This is most useful for logs from personal programs and the like and is primarily a means users can employ to preserve vital files from accidental removal. The user or root may remove this flag at any time.

uchg

Only the owner or root can set the user immutable flag. Like the schg flag, the user immutable flag prevents a user from changing the file. Again, root can override this, and the user at any securelevel can remove it.

Setting and Removing File Flags

Set file flags with chflags(1), giving the desired flag and the filename as arguments. For example, to be sure that your kernel isn't tampered with, you could do this as root:

 # chflags schg /bsd 

This would prevent both an intruder and a legitimate administrator from removing the kernel file.

You can also recursively change the flags on a directory tree with the "-R" argument. For example, to make /bin immutable use this command:

 # chflags -R schg /bin 

And boom! Your basic binaries cannot be changed. Upgrades, maintenance, and the placing of trojans just got a lot more difficult.

To remove a flag, use chflags(1) and a "no" in front of the flag name. For example, to unset the schg flag we just set on the kernel, enter this command:

 # chflags noschg /bsd 

Remember, you must be running at securelevel 0 or below to unset schg and sappnd flags. So, without further ado, we'll discuss securelevels and what they mean.