Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Absolute BSD - The Ultimate Guide To FreeBSD (2002).pdf
Скачиваний:
25
Добавлен:
17.08.2013
Размер:
8.15 Mб
Скачать

..........................................................................................

#chown dns:dns file1

#chmod 664 file1

#ls −l file1

−rw−rw−r−− 1 root dns 1188 Sep 14 09:35 file1

#

..........................................................................................

Your staff can now do their jobs without the root password, and your files are immune to tampering by the system process that uses them.

[3]In UNIX, "simplify" frequently means "make easier to say and faster to type, but more difficult to understand."

[4]You can have four−digit modes in special circumstances. See chmod(1) for details. You don't normally use four−digit modes except on device nodes and other special files.

File Flags

UNIX filesystem permissions are standard across various versions of UNIX, and BSD extends the permissions scheme with file flags. These flags work with permissions to increase your system's security. Some of these flags are used for non−security−related functions, but the ones we're interested in here are security related.

Note Many of the flags have different effects depending on the system securelevel, which will be covered shortly in the "Securelevels" section. For the moment, just nod and smile when you encounter a mention of securelevel; all will become clear in the next few pages.

The following are the security−related file systems flags:

sappnd The system−level append−only flag can only be set by root. Files with this flag can be added to, but cannot be removed or otherwise edited (which is particularly useful for log files). Setting sappnd on a .history file can be interesting if your system is compromised. Since a common intruder tactic is to remove.history or to symlink it to /dev/null so that the admin cannot see what was done, sappnd ensures that script kiddies cannot cover their tracks in this manner. It's almost funny to watch the record of someone trying to remove a sappnd file. You can see the attacker's frustration grow with the various things she tries. (It is better, of course, for your system not to be hacked at all!) This flag cannot be altered when the system is running at securelevel 1 or higher.

schg The system−level immutable flag can only be set by root. Files with this flag set cannot be changed in any way, neither edited, moved, nor replaced. Basically, the filesystem itself will prevent all attempts to touch this file in any way. This flag cannot be altered when the system is running at securelevel 1 or higher.

sunlnk The system undeletable flag can only be set by root. The file can be edited or altered, but it cannot be deleted. This is not as secure as the previous two flags because if a file can be edited, it can be emptied. It's still useful for certain circumstances, however. I've used it to solve problems when a program insisted on deleting its own log files when it crashed. It's not generally useful to set on any standard system flags. This flag cannot be altered when the system is running at securelevel 1 or higher.

148

uappnd The user append−only flag can only be set by the file owner or root. 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 to keep users from shooting themselves in the foot. The owner or root can remove this flag at any time.

uchg The user immutable flag can only be set by the owner or root. Like the schg flag described earlier, the user immutable flag prevents a user from changing the file. Again, root can override this, and it can be disabled by the user at any securelevel. This flag helps to prevent mistakes, but not to secure the system.

uunlnk The user undeletable flag can only be set by the owner or root. A file with this flag set cannot be deleted by the owner, though root can override that, and this flag can be turned off. This flag is mostly useless, but like the other user flags can be helpful in preventing mistakes.

Viewing a File's Flags

You can see a file's flags with ls −lo:

..........................................................................................

# ls −lo important

−rw−r−−r−− 1 mwlucas mwlucas uchg 0 May 11 19:51 important

..........................................................................................

The uchg in the preceding listing tells us that the user immutable flag is set. In comparison, if a file has no flags set, it looks like this:

..........................................................................................

# ls −lo unimportant

−rw−r−−r−− 1 mwlucas mwlucas − 0 May 11 19:52 unimportant

#

..........................................................................................

The dash in place of the flag name tells us that no filesystem flag has been set.

An out−of−the−box FreeBSD doesn't have many files marked in this way. You can certainly mark anything you want in any way desired, however. On one system that I fully expected to be hacked, I went berserk with chflags −R schg in various system directories to prevent anyone from replacing system binaries with Trojaned versions. It might not stop an attacker from getting in, but it made me feel better to imagine how frustrated an attacker would be once he got a command prompt.

Setting Flags

You can set flags with the chflags(1) command. For example, to be sure that your kernel isn't replaced, you could do this:

..........................................................................................

# chflags schg /kernel

..........................................................................................

This would keep anyone from replacing your kernel: both an intruder and you.

149