Date: Tue, 30 Nov 1999 01:20:39 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: scanner@jurai.net Cc: Doug Rabson <dfr@nlsystems.com>, "David O'Brien" <obrien@FreeBSD.ORG>, Mark Murray <mark@grondar.za>, Kris Kennaway <kris@hub.freebsd.org>, freebsd-audit@FreeBSD.ORG Subject: Re: FreeBSD security auditing project. Message-ID: <Pine.BSF.3.96.991130011005.3225A-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.20.9911240408270.28165-100000@sasami.jurai.net>
next in thread | previous in thread | raw e-mail | index | archive | help
(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 belongs) On Wed, 24 Nov 1999 scanner@jurai.net 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. Chris, 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 robert@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@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.991130011005.3225A-100000>