Re: time for some OpenBSD-style auditing?
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
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.
--
"... being a Linux user is sort of like living in a house inhabited
by a large family of carpenters and architects. Every morning when
you wake up, the house is a little different. Maybe there is a new
turret, or some walls have moved. Or perhaps someone has temporarily
removed the floor under your bed." - Unix for Dummies, 2nd Edition
-- found in the .sig of Rob Riggs, rriggs@tesser.com
Reply to: