(Damn, go away for Thanksgiving and fall behind on -CURRENT, and miss out
on large interesting and fast-paced discussions!  I am now subscribed to
the new -audit, and probably missed some messages.  I've Bcc'd this to
-current, but CC'd to -audit under the assumption that that is where it

On Wed, 24 Nov 1999 [EMAIL PROTECTED] wrote:

> On Wed, 24 Nov 1999, Doug Rabson wrote:
> > We need to put audit tags into the source tree when a file is audited.
> > That allows the diffs to be audited later which should be a smaller job
> > and then the audit tag slides forward.
>       Not to interrupt in the middle of this discussion but you might
> want to check with robert watson before you guys get too deep here since
> he is working on a FUNDED Posix.1e implementation for FreeBSD. And has
> already posted some EARLY MAC code. It might be usefull to work with him
> as well. Just a thought.


That would be the "other" audit -- this auditing is source code
auditing for bugs in the code.  The POSIX.1e auditing would be event
logging/etc.  Sadly, they have the same name, and I'm not sure which
is the more appropriate activity to have the name :-).  

That said, there have been past projects to audit the FreeBSD source
code, but this seems to have the most steam behind it so far, and I
hope it goes forwards.

It's important to note that source code auditing is not the only
thing that makes OpenBSD more secure -- strong crypto, careful
thinking through of information leaking, etc, are also very important.
There are many bugs in the security design, not just in the
implementation, important as the implementation may be.

Strings in C seem to be a huge source of security problems, but needless
to say even if we had a better string library, there would still be
security problems :-) -- poorly thought out suid programs, incorrect use
of setuid to create sandboxes (man, uucp, etc, etc), bad permissions,
reliance on privacy of environmental variables, poor random number
seeding, misunderstandings about euids/uids/reuids/etc in the context of
debugging and tracing, weak defense of /dev/kmem, etc, etc, and there are
dozens and dozens of such issues. 

POSIX.1e extensions attempt to address some of these issues by providing
least privilege capabilities, finer grained access control, as well as
trusted system behavior such as mandatory access control and auditing. 

This all also requires serious thought.  Source auditing is a great
step forwards, however, as it clears up the most commonly exploited
security holes that make for bad press and lots of bugtraq
announcements.  :-)

  Robert N M Watson 

[EMAIL PROTECTED]              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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to