[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: time for some OpenBSD-style auditing?

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 debian-security-request@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> > 
> 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
email galt@inconnu.isu.edu

Reply to: