BSD Newsletter.com
   Front | Info | Lists | Newsfeeds | Study Guide | What is BSD?
Advertisement: The OpenBSD PF Packet Filter Book: PF for NetBSD, FreeBSD, DragonFly and OpenBSD

BSD Links
·New Links
·Advocacy
·Drivers
·Events
·Flavours
·FAQs
·Guides
·Programming
·Security
·Software
·User Groups

This is the BSDA Study Guide Book written via a wiki collaboration. This is a work in progress. You may contribute to or discuss this specific page at http://bsdwiki.reedmedia.net/wiki/View_and_modify_file_flags.html.

View and modify file flags

Author: Ivan Voras IvanVoras FreeBSD

Concept

Understand how file flags augment traditional Unix permissions and should recognize how to view and modify the immutable, append-only and undelete flags.

Introduction

All current BSD system support an additional mechanism for fine-grained tuning of file security called "file flags". Though similar, this should not be confused with standard Unix file access modes. The flags are:

  • archived - The file may been archived
  • opaque - The directory is opaque when viewed through a unionfs stack
  • nodump - The file is to be ignored by backup utilities (like dump(1))
  • sappend - The file can only be appended to (cannot change it's contents) by any and all users
  • schange - The file can not be changed by any and all users
  • sunlink - The file cannot be unlinked
  • uappend - The file can only be appended to by its owner
  • uchange - The file can only be changed by its owner
  • uunlink - The file can only be unlinked by its owner

Some of these flags can only be (re)set by the super-user. This includes archived and all s* flags.

A very important aspect of file flags is how they interact with securelevel. When securelevel is set to 1 or above, flags cannot be modified even by root, thus enabling creation of fortified system that cannot be damaged (deliberately or not) by the superuser. Note: Secure levels are covered in Determine the system's security level.

The ideas behind the security-related flags are:

  • Log files should be append-only, thus preventing an attacker to mask his trail by modifying them
  • In a similar vein, log files should be prevented from deletion (i.e. unlink)
  • System configuration files, SUID files, and other (at administrator's discretion) must be prevented from unauthorized change.

Downsides of this approach are that most administrative tasks must be done in single user mode on the machine's console, and that log rotation cannot work or is very tricky to do.

Some utilities have been modified to natively support file flags. For example, ls accepts -o argument to display file flags for each file.

Examples

> chflags uappend important.log
(succeeds)

> ls -l important.log
-rw-r--r--  1 ivoras  ivoras   172 Jan 20 00:42 important.log

> ls -lo important.log
-rw-r--r--  1 ivoras  ivoras  uappnd 172 Jan 20 00:42 important.log

> echo garbage > important.log
important.log: Operation not permitted.

> echo garbage >> important.log
(succeeds)

> mv important.log unimportant.log
important.log: Operation not permitted

Practice Exercises

  1. Set sappend flag to /var/log/security and /var/log/userlog. Investigate what happens when log rotation is attempted.
  2. List files in /usr/bin and inspect their flags - notice that some are marked schange (or schg) by default.
  3. Not all utilities understand BSD file flags - check your backup and file management tools.

More information

ls(1), chflags(1)



Front | Information | Lists | Newsfeeds