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
damn.
email galt@inconnu.isu.edu
Reply to: