Date: Fri, 12 Mar 1999 13:52:21 +1300 From: Andrew McNaughton <andrew@squiz.co.nz> To: Nicholas Brawn <nick@citadel.com.au> Cc: mike@seidata.com, andrewr <andrewr@slack.net>, freebsd-security@FreeBSD.ORG, jbowie@slack.net Subject: Re: disapointing security architecture Message-ID: <199903120052.NAA09299@aniwa.sky> In-Reply-To: Your message of "Fri, 12 Mar 1999 09:31:52 %2B1100." <199903120830.TAA28219@goblin.citadel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> I'm also interested. However, if I recall correctly, the problem last time > was that nobody actually sat down and did the work. There were plenty of > ideas, but when it came to the crunch, nobody wanted to put in the effort. > > Nick As I recall, discussion turned to concerns over who was qualified to do the work, which seemed rather silly. No security auditing project is going to be complete. No auditor is going to be perfect. Every bit counts. Seems to me that one of the most useful things that could be set up would be a repository of information on what's been checked when by who, and what people have suggested needs to be gone over. I imagine this would be something similar to gnats, or be an adaption of that package. A repository where you could reports identifying problems, suggesting solutions, describing auditing which has been done etc. Should be structured so that you can goto the repository and find out all that's been done on a piece of code you're interested in. I'm interested by this project, but realistically, I can't commit much time to it. Every so often though I check out something that concerns me and as things are whatever information I gather tends not to be made available to others unless it amounts to a confirmed vulnerability. For instance, last year I spotted the buffer overflow potential in the sshd 1.2.25 logging routine which was later the subject of much discussion in bugtraq. I didn't have the time to go through and check out all the places in the code where the routine was called from, and the ones I did check seemed OK, so it didn't go anywhere. An auditing effort needs to have a way to make use of preliminary results like that. There's a bit of work involved in setting up a repository for this sort of information, but it allows the breaking down of the hugs task of auditing an OS into a lot of small tasks that can nonetheless still be part of a whole project. Andrew McNaughton -- ----------- Andrew McNaughton andrew@squiz.co.nz http://www.newsroom.co.nz/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903120052.NAA09299>