|Subject:||Re: Time to redirect! (Was: Re: Topics for -security vs. topics for -audit)|
|From:||Kelly Yancey (kby...@posi.net)|
|Date:||Nov 30, 1999 9:42:56 pm|
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"
I'de be glad to help where I can as code auditor. My "resume" includes 12 years of programming experience: about 10 years of which are C (the most prodigious amount of coding being in the last 6 years). Overlap that with several years of x86 assembly programming and a few years of the standard unix utility fare (perl, sh, awk, etc). Not to mention the now useless years of Pascal :)
"Volunteer to help with web page setup"
For the past 5 years, this has been how I spend my days. I've been dreaming in HTML, SQL, PHP, and perl for months straight :) It's gotten so bad that when I got home I kept going and put up database-driven sites for the distributed.net Team FreeBSD and am currently working on the BSD Driver Database. This is where I think I can help the project the most.
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 <auditor> 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 <auditor>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!! :-)
I submitted some ideas I had in these regards to -current last week. See http://docs.freebsd.org/cgi/getmsg.cgi?fetch=357598+0+archive/1999/freebsd-current/19991128.freebsd-current
Personally, I'm leaning toward a combination of PHP and perl. Basically, PHP to provide rapid development of the web user-interface, perl to provide back-end automated processing such as monitoring commits. I haven't played with CTM yet, but I would definately investigate using a perl script to catch the CTM-generate e-mail and flag functions (or if you prefer, files) as modified. Perhaps I've gone SQL happy, but it is my first inclination to store the project progress in a SQL database (either mySQL or postgreSQL, I use mySQL for most projects, so I'm leaning that direction). I think SQL would be an asset here in that we gain: * a standardized way to access the project data * an efficient method of retrieving and updating that data * we don't have to write our own data access interfaces so we have a faster development time
Anyway, I'm looking forward to working on this, both the audit itself, and hopefully the web site.
Your willing servant,
-- Kelly Yancey - kby...@posi.net - Richmond, VA Director of Technical Services, ALC Communications http://www.alcnet.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message