Date: Thu, 2 Dec 1999 21:42:14 +0100 (CET) From: Georg Wagner <g.wagner@datacomm.ch> To: FreeBSD-gnats-submit@freebsd.org Subject: bin/15229: mtree - different from mtree in NetBSD 1.4 Message-ID: <199912022042.VAA00758@brain.hoengg.ch>
next in thread | raw e-mail | index | archive | help
>Number: 15229
>Category: bin
>Synopsis: mtree - different from mtree in NetBSD 1.4
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Thu Dec 2 12:50:01 PST 1999
>Closed-Date:
>Last-Modified:
>Originator: Georg Wagner
>Release: FreeBSD 2.2.8-STABLE i386/ all releases
>Organization:
-
>Environment:
>Description:
In NetBSD the functionality of mtree was changed to recognise and
set/unset the file flags (schg, sappnd). This functionality is
extremely usefull in environments with high security risks.
Original proposal of A. Wennmacher:
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
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
>How-To-Repeat:
>Fix:
Take the mtree out of NetBSD 1.4 and port it to FreeBSD. Only minor
changes are neccessary.
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912022042.VAA00758>