From owner-freebsd-audit Tue Nov 30 11:39:40 1999 Delivered-To: freebsd-audit@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id 3223E159E8 for ; Tue, 30 Nov 1999 11:39:24 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id VAA17777 for ; Tue, 30 Nov 1999 21:39:22 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199911301939.VAA17777@gratis.grondar.za> To: freebsd-audit@FreeBSD.ORG Subject: Time to redirect! (Was: Re: Topics for -security vs. topics for -audit) Date: Tue, 30 Nov 1999 21:39:21 +0200 From: Mark Murray Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK, we have definitely got critical mass, and we certainly have momentum. Now we need direction. The purpose of this list is not to discuss architectural issues. We are here to _audit_. If a problem crops up, and there is a code/style/security issue with it that needs to be addressed, then please take that to the most appropriate of -arch, -current or -security, and bring the answer back here. > Even in the past two days, we've seen significant discussion > that should probably be taking place on -security: selecting a > pseudo-random number generator does relate to source code, but > it's also an issue our crypto-intense folks should be keeping an > eye on, even those that are not into detailed coding. Where to > use the pseudo-random number generator becomes more of an auditing > issue--places where it should be used, but some approximation is > currently used, or where a poor seed is used. The same goes for > default conditions for using the prng in network and pid code, > etc. This is discussion relevant to a wide audience. Right! What I want to organise now is the various groups; in the beginning, I had a lot of folk volunteering for various things; I'd like you to please do this again (for the record), and in such a way that we can all find you on the appropriate mailing list archives. Please could you volunteer for each of the following classes by sending a mail to this list with your choice of subject(s) (more than one mail is OK): "Volunteer as code auditor" "Volunteer to help with web page setup" ...&c. Please write a _very_short_ resume describing why you should do this job in the body of the mail (purely for reference). Eventually you'll land up on the rogue's gallery as "one of the team". I'd like the webmasters to come out and help set up a hypertext version of the source tree (not the actual source, just the directory structure), and a method of submitting results. So far, the results (c|sh)ould be: 1) Code examined by and deemed a) abuse of i) string library functions (str* b* s*printf etc). ii) temp file races and symlink abuse iii) buffers by "inline" code iv) SUID/SGID privelige v) secret data (password buffers, environment variables, &c) vi) &c... b) clean (?) -Wall -Weverything -Werror as appropriate. (the intent is not to force the committal of these options, but to use the compiler tools (heck, even lint(1)) to automate as much of this as possible). c) to have adopted (where appropriate) such fixes/features offered by our sister BSD's. Separate s may do individual parts, but this must be tracked. So far, I lean towards the unit of audit being the file, not the function, but I suspect that with good tools, this could change in the future. There must be a mechanism for auditors to "claim" code for auditing (to avoid duplication of effort), but there must be a time limit to prevent tracts of code being "locked out" of the audit process. I request the simplest possible implementations; CGI in perl? Great! CGI in C? Wonderful! Multi-megabyte system on NT/VB? Naaah. Ideas? Cool. Volunteers? Better. Code? Aaaaah!! :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message