Here is my file flags proposal. Let's start the debate.

--------------------------------------------------------------------------------
                         File Flags Proposal

CONTENTS
--------

0.  Abstract
1.  Introduction
  1.1  Kernel security levels
  1.2  4.4BSD file flags
  1.3  Added security with file flags set
  1.4  Impact on system administration
2  Setting/Unsetting file flags
  2.1  mtree(8)
  2.2  Using mtree(8) for file flags
3  Flags specifications


0. Abstract. It is proposed that mtree(8) be slightly changed to support
             the administration of the schg and sappnd file flags. A method
             is described how mtree can be used to improve system security
             by setting and unsetting the schg and sappnd flags in a
             consistent way. A suggestion for file flags defaults is made.

1.  Introduction
----------------

If you are familiar with kernel security levels and file flags, continue
with section 1.3.


1.1  Kernel security levels
---------------------------

The NetBSD kernel operates at different kernel security levels:

At level 0 there are no security level related restrictions; immutable
and append-only flags (see chflags(1) and chflags(2) for more information
on file flags) may be set and unset, devices may be read or written subject
to their permissions.

At level 1 superuser immutable and append-only flags may not be unset, disks
for mounted filesystems, /dev/mem, and /dev/kmem are read-only.

At level 2 disks are always read-only, whether mounted or not, in addition
to the security features of level 1.

During operation in single user mode, the kernel in general runs at security
level 0. While transitioning to multi user mode, init(8) raises the security
level to 1. Using the sysctl(1) command, the security level may later even be
raised to 2. If it is desired to run the system permanently at security level 0
"options INSECURE" may be specified in the kernel configuration file which
inititalizes the security level to -1.

See init(8) and /usr/include/sys/systm.h for more information on security
levels.


1.2  4.4BSD file flags
-----------------------

The chflags() and fchflags() system calls, and the chflags(1) command first
appeared in 4.4BSD. They implement the following flags:

flag name  flag bit
-------------------------------------------------------------------------------
nodump     UF_NODUMP     Do not dump the file.
uchg       UF_IMMUTABLE  The file may not be changed.
uappnd     UF_APPEND     The file may only be appended to.
opaque     UF_OPAQUE     The file (if a directory) is opaque for union mounts.
arch       SF_ARCHIVED   The file is archived.
schg       SF_IMMUTABLE  The file may not be changed.
sappnd     SF_APPEND     The file may only be appended to.
-------------------------------------------------------------------------------

schg and sappnd are super-user only flags, uchg and uappnd are the equivalent
flags for unprivileged users.

If schg is set on a file, even root may not delete, rename or truncate the
file. Such a file is called immutable. Immutable directories may not be
renamed nor may files be added or removed.

If sappnd is set on a file, the file is immutable, except that data may be
appended to that file. In the case of directories, new directory entries may
be created, and files in a directory may be renamed, but no files may be
removed.

See chflags(1) and chflags(2) for more information on file flags.


1.3  Added security with file flags set
---------------------------------------

Stock NetBSD distributions do not make use of the schg and sappnd flags for
their system files.

Setting these flags is not without problems because once set, systems have in
general to be taken to single user mode to undo this operation. And, as yet
there was no tool which sets/unsets the flags automatically on a large number
of files.

However, having most system files with the schg and sappnd flags set increases
system security dramatically. Imagine the following scenario:

A hacker managed to break in into your system and even managed to become root.
As a first step, he tries to cover up his traces by changing the system log
files /var/log/authlog, /var/log/lastlog, and /var/log/wtmp. No chance, the
are sappnd.

The typical next step is to replace some of your system binaries with Trojan
horses. But this won't work on a flags protected system. Decepted, the hacker
tries to erase your system: /bin/rm -rf /. No, this won't work for him either
(except for the user data, having a backup is still a good idea).

A more clever hacker will probably try to unset the schg and sappnd flags.
But how? He breaked in over a network connection and taking the system to
single user mode will close the network connection. So that will not work.
He will have to prepare the system while in multiuser mode to change the
file flags during the next reboot. But that will also not work, because all
files run during startup (/etc/rc, /etc/rc.local and all binaries called from
them) are protected by schg. No luck.


1.4  Impact on system administration
-------------------------------------

You get nothing for free. If you decide to set the schg and sappend flags,
you may still do some system administration while in multiuser mode (like
adding users), but most of the more critical work has to be done at single
user mode. It's upon you to decide whether you want ease of administration
or security.

Basically, you have the following three choices:

1) To not set schg and sappnd on any files.
2) To use the defaults for the schg and sappnd flags on system files
   (I will propose the defaults in section 3).
3) To customize the settings of schg and sappnd flags on system files according
   to your needs.

Your choice will have the following impact:

1) None. Nothing changes for you as compared to now.
2) Most of system administration will have to be done during single user
   mode. Your security is drastically improved.
   The choice of applying the defaults can be undone with one single
   command (during operation in single user mode).
3) Similar to 2. This choice may be undone using two simple commands per
   file system (during operation in single user mode).

I will describe how to unset schg and sappnd for all system files using
mtree(8) in the next section. Note, however, that for standard system
administration, it is often sufficient to unset the flag by hand, edit the
file, and set it again by hand when done.


2  Setting/Unsetting file flags
-------------------------------

2.1  mtree(8)
-------------

mtree(8) is the utility that will take care to set/unset the schg and sappnd
file flags in a consistent way. Matthew Green made mtree(8) flags-aware, and
I have added two options to mtree(8) (described below) that can specifically
be used for setting/unsetting schg and sappnd (I have sent my patches to
Matthew Green).

mtree(8) compares the file hierarchy rooted in the current directory against
a specification. mtree(8) has options (-U and -u) to modify the owner, group,
and permissions of existing files to match the specification and create any
missing directories.

I have added the -i and -m options. mtree now has the following semantics:
sappnd and schg are treated as special flags. Normally, mtree does not affect
them.

If -u and -i are given, mtree will set the flags exactly as in the
specificationified. -u alone will set the specified flags with the exception
of sappnd and schg, leaving these untouched. -u and -m will set the flags as
specified, but will clear the schg and sappnd flags.

If given without -u, -i will set schg and sappnd (leaving all other flags
untouched), -m will reset them.


2.2  Using mtree(8) for file flags
----------------------------------

If you want to set the schg/sappnd flags, you would simply run

% cd /
% mtree -i -f /etc/mtree/NetBSD.dist

or

% mtree -i -u -f /etc/mtree/NetBSD.dist

To unset the schg/sappnd flags:

% cd /
% mtree -m -f /etc/mtree/NetBSD.dist


If you want to customize your flags settings, you can do that by applying
the defaults and changing them according to your needs (using the chflags
command). As a next step create your own specifications file:

% cd /
% mtree -x -c > /etc/mtree/myroot.spec

% cd /usr
% mtree -x -c > /etc/mtree/myusr.spec

You then can unset all schg and sappnd flags using:

% cd /
% mtree -x -m -f /etc/mtree/myroot.spec
% cd /usr
% mtree -x -m -f /etc/mtree/myusr.spec

etc.


3  Flags specifications
-----------------------

The flags specifications should be included in /etc/mtree/NetBSD.dist.
To make it short, here is my suggestion how to set schg and sappnd on
the NetBSD system files:

/				sappnd
	/boot			schg
	/netbsd			schg
/bin				schg
	/bin/*			schg
/dev				sappnd
	/dev/*			schg
/etc				sappnd
	/etc/aliases		sappnd
	/etc/aliases.db		none
	/etc/bootptab		sappnd
	/etc/changelist		sappnd
	/etc/csh.cshrc		schg
	/etc/csh.login		schg
	/etc/csh.logout		schg
	/etc/daily		schg
	/etc/daily.conf		schg
	/etc/defaultdomain	schg
	/etc/dhclient-script	schg	(??)
	/etc/disktab		sappnd
	/etc/disktab.preinstall	none
	/etc/dm.conf		none
	/etc/dumpdates		none
	/etc/floppytab		sappnd
	/etc/fstab		schg
	/etc/fstab.sd		none
	/etc/fstab.wd		none
	/etc/ftpchroot		sappnd
	/etc/ftpusers		schg
	/etc/ftpwelcome		none
	/etc/gettytab		none	(??)
	/etc/group		none
	/etc/hosts		none
	/etc/hosts.equiv	schg
	/etc/hosts.lpd		schg
	/etc/inetd.conf		schg
	/etc/ld.so.conf		schg
	/etc/lkm.conf		schg
	/etc/localtime		schg
	/etc/mail.rc		schg
	/etc/man.conf		none
	/etc/master.passwd	none
	/etc/mk.conf		none
	/etc/monthly		schg
	/etc/monthly.conf	schg
	/etc/motd		none
	/etc/mrouted.conf	none	(??)
	/etc/mygate		schg
	/etc/myname		schg
	/etc/netstart		schg
	/etc/networks		schg
	/etc/newsyslog.conf	schg
	/etc/ntp.conf		schg
	/etc/ntp.drift		none	(should be moved to /var)
	/etc/passwd		none
	/etc/phones		sappnd
	/etc/printcap		none
	/etc/profile		schg
	/etc/protocols		schg
	/etc/pwd.db		none
	/etc/rbootd.conf	schg
	/etc/rc			schg
	/etc/rc.conf		schg
	/etc/rc.lkm		schg
	/etc/rc.local		schg
	/etc/rc.subr		schg
	/etc/remote		sappnd	(??)
	/etc/resolv.conf	schg
	/etc/rmt		schg
	/etc/rpc		schg
	/etc/security		schg
	/etc/security.conf	schg
	/etc/sendmail.cf	schg
	/etc/services		schg
	/etc/shells		schg
	/etc/skeykeys		none	(??)
	/etc/spwd.db		none
	/etc/syslog.conf	schg
	/etc/ttys		schg
	/etc/weekly		schg
	/etc/weekly.conf	schg
/etc/mtree			sappnd
	/etc/BSD.pkg.dist	schg
	/etc/BSD.x11.dist	schg
	/etc/NetBSD.dist	schg
	/etc/special		schg
/mnt				none
/kern				none
/sbin				schg
	/sbin/*			schg
/tmp				none
/var				sappnd
/var/account			sappnd
	/var/account/*		sappnd
/var/at				sappnd
/var/at/jobs			sappnd
/var/at/spool			sappnd
/var/backups			none
/var/crash			none
/var/cron			sappnd	(1)
/var/cron/tabs			none
/var/db				none
/var/db/ns			none	(??)
/var/db/pkg			none
/var/games			none	(2)
/var/log			sappnd
	/var/log/*		none
	/var/log/authlog	sappnd	(1)
	/var/log/lastlog	sappnd
	/var/log/wtmp		sappnd	(1)
/var/log/rdist			none
/var/mail			none
/var/msgs			none
/var/preserve			none
/var/quotas			none
/var/run			sappnd
/var/rwho			none
/var/spool			sappnd
/var/spool/secretmail		none	(??)
/var/spool/lock			none
/var/spool/lpd			sappnd
	/var/spool/lpd/*	none
/var/spool/mqueue		none
/var/spool/ftp			schg
/var/spool/ftp/bin		schg
/var/spool/ftp/etc		schg
/var/spool/ftp/hidden		schg
/var/spool/output		none
/var/spool/sockets		none
/var/spool/uucp			none	(??)
/var/spool/uucppublic		none	(??)
/var/tmp			none
/var/tmp/vi.recover		none
/var/yp				sappnd
/var/yp/binding			none	(??)
/proc				none
/altroot			sappnd
/root				none
/home				none
/stand				schg
	/stand/*		schg	(3)
/usr				sappnd
/usr:	all subdirectories	schg
/usr:	all files		schg
	with the following exceptions:
/usr/share/man			none	(4)
/usr/share/sendmail/cf		sappnd
/usr/pkg			sappnd
/usr/src/sys/arch/*/compile	none
/usr/src/sys/arch/*/conf	sappnd

(1): Syslog framework will have to be changed
(2): root, don't play games!
(3): currently not applicable
(4): whatis.db should be moved to /var/man

-- 
Dr. Alexandre Wennmacher
Institut fuer Geophysik und Meteorologie         wennmach@geo.Uni-Koeln.DE
Universitaet zu Koeln                            phone  +49 221 470 - 3387
D-50923 Koeln                                    fax    +49 221 470 - 5198