How tamper proof is a running kernel?

[Robert Watson]

On Sat, 20 May 2000 careilly at thecia.ie wrote:

> Anyone got any suggestions for reading material? I'm interested in knowing
> how easy/hard/impossible it would be for an intruder to alter a running kernel
> in order to bypass audit mechanisms. 

This is one of the things that the BSD 4.4 securelevel code is supposed to
address -- in essence, it's a (very) limited form of integrity protection,
preventing processes from modifying the running kernel, loading new
modules, directly modifying disk devices/hardware, etc, once the
securelevel is raised.  In particular, it provides a set of file flags
(immutable, append-only, etc) intended to protect boot-time programs and
configuration files, as well as log file integrity.

However, in practice securelevels are a very limited and inconvenient form
of protection.  While they do protect against processes with root
privileges, dealing with the reboot issue is hard -- in teh default BSD
installs, the securelevel is not raised until after a substantial part of
the boot process has run (so that file systems can be checked, mounted, et
al).  As a result, a vast number of files must be protected using the
"schg" flag, limiting the usefulness of the machine from an administrative
perspective.  For example, it is necessary to protect the rc script and
all files it depends on, etc, meaning marking numerous directories as
schg.  General purpose integrity-based MAC policies such as a Biba
integrity model are far more flexible.

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message