On Thu, 28 Dec 2000, Andres Salomon wrote: > On Thu, Dec 28, 2000 at 04:46:00PM -0800, Joe Buck wrote: > > > > Notice that security holes fall into classes? One category of hole > > should be easy to eliminate from Debian by instituting a code auditing > > requirement. I'm referring to insecure creation of temporary files, > > allowing for symlink attacks. Now that we all know what this hole looks > > like, it should be simple to eliminate. > > > > The other big source of common security holes, buffer overruns, is tougher > > to eliminate completely because they can be tough to spot. But there's no > > excuse now for anyone to put out another GNU/Linux distribution containing > > a program that creates temporary files insecurely. If I were Debian > > dictator (and I'm not even a debian developer, though I am what you guys > > call an "upstream developer" -- I'm on the GCC steering committee), I'd > > add a requirement that every package owner certify that he has checked the > > package s/he maintains for a list of common security problems, and that > > all problems found have been fixed. > > Sounds lovely, in theory. However, judging by the number of open bugs > in some packages, out of date packages, etc, what makes you think > developers would take this more seriously? What proof does one have
Actually let me chime in at this point and say that personally I'd probably prefer non-developers auditing. If you adopt code as an auditor, you lose the objectivity to be able to junk bad code relatively quickly... Auditors should have as little to do with a piece of code they're auditing as possible: preferably not even use it. This way they don't fall "in love" with the code and do what's necessary for security... > that someone actually did a _quality_ audit of code? Futhermore, do > developers have the skills necessary to audit? If I package foobar-1.2, > and it's written in python, yet have no knowledge of python, how can > I possbily do any type of audit? Futhermore, if I package (and audit) > foobar-1.2, and then upstream releases foobar-1.3; do I re-audit? Do I > just package and hope there were no vulnerabilities introduced between > versions? > > > > > I call this "OpenBSD style" because they are the only folks currently > > doing this -- everyone else takes a reactive approach to security > > problems, not fixing them until someone posts a root exploit. We > > can do better. > > I assume, following the OBSD lead, you're suggesting auditing only > base (and possibly admin). What about various daemons, which are > scattered around various sections (apache->web, bind->net, etc)? > > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > > Personally, I don't see any type of auditing happening any time soon > by developers of their packages. I wouldn't expect it, either; they're > there to package, not to work on the source code of the packages > (otherwise, they'd be working upstream :). I could see a core team > of people (not necessarily debian developers, but simply > volunteers) auditing and reporting bugs (and hoping developers > actually fix the bugs); not much organization is needed for that, > however. > > > -- Pardon me, but you have obviously mistaken me for someone who gives a damn. email [EMAIL PROTECTED]
