Audit specifications

[paleph at pacbell.net]

Andrew

I implemented the audit subsystem (kernel and userspace) for Solaris 2.*.

> - Did you use a standard to base your work off of?
> - If so, which standard? Pluses and minuses to the spec. used?

	No. There were no standards when I did the work for Sun.
	We followed the POSIX efforts at the beginning then decided
	that we didn't have time to wait for closure.

	The major problem we saw that each POSIX meeting resulted
	in a new design; each company wanted their implementation
	to be the standard. I understand the same thing happened
	with the other security subgroups. I personally consider
	POSIX mostly dead. There are only 3 standards: microsoft,
	linux, and Solaris (to some extent).

> - If not, in what manner did you base your work off of?
> - Personal experience? What others have done?

	SunOS already had an audit package. However, we decided not
	to move it to Solaris due to it's design and implementation limitations.
	We redid everything from scratch based on an initial set of
	requirements:

	1. auditing needed to meet requirements of orange book and CMW
	2. auditing subsystem needed to be portable over CMW, a (now dead)
	   MLS project, and Solaris 2.*. We wanted to maintain code for only
	   one audit subsystem. Modularity was thus high on our list of
	   requirements.
	3. Needed to be invisible to the user. The SunOS audit code, for
	   example, disabled the fchdir(2) and fchroot(2) system calls.
	   It also did not handle chroot properly and had problems with
	   fchdir and fchmod.
	4. auditing should not degrade performance significantly
	5. auditing implementation should not be intrusive to the kernel or
	   utilities. The original SunOS audit code had about 600 places where
	   it interacted with the kernel. In Solaris we reduced this to about
	   50.
	6. An audit record should be able to completely describe an event.
	   This was to simplify audit record analysis.

	Hard parts: STREAMS presented the most difficult problems since we
	had to maintain state across system calls. Auditing of ioctl(2)
	operations were also messy and caused problems. Solaris also supported
	loadable system calls which we never handled well. Another area where
	we had problems was with system administration. A big part of the
	UNIX system is designed to be administrated via vi. These
	operations were not easy to audit.

	The major problem was support; we were constantly being surprised by
	changes to the kernel and utilities. Things would silently stop being
	audited due to some kernel or application change so we were constantly
	doing bug fixes as we discovered these problems.

	We also started to investigate better non-attributable audit record
	generation due to network and IPv6/IPsec operations.

------

Paul Fronberg
paleph at pacbell.net

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