Subject: Security information page

From: "Magnus Hagander" <[email-masked]>
Date: Sun, 27 Nov 2005 13:46:13 +0100

Per some discussion last week, I've put together a page with security
information. Basically an introduction written by Simon and a table I
pulled together by going through the CVE list and matching it up with
our cvs versions.

As it makes some statements on behalf of the beleifs of the PGDG (the
introduction), I'm giving everybody a good chance to complain and
correct before it goes onto the actual website. Oh, and please also
point out any incorrectness or missing information in the actual
table...

The link for the in progress version is
http://magnus-master.pgadmin.org/support/security.

//Magnus

---

From: Tom Lane <[email-masked]>
Date: Sun, 27 Nov 2005 12:16:33 -0500

> pulled together by going through the CVE list and matching it up with

: All security issues are always fixed in the next major release, when
: it comes out.

Perhaps "all known security issues..."  The statement as made is
hopelessly hubristic.

Please remove the statements about how we will respond within X hours or
days.  That has nothing to do with reality.  (Reality is that we are
often constrained by CVE publication dates if the fix is trivial, and
if it isn't trivial then it won't be fixed instantly anyway.)  I'd lose
the whole paragraph beginning "PGDG's aim ..."

I think the bit about "Our goal is to gain and maintain CVE-compatible
status" is bogus.  As near as I can tell, Mitre's definition of CVE
compatibility applies to security products (eg, vulnerability scanners)
which Postgres is not.  You could maybe say that this one web page is
something that could apply for CVE compatibility status, but are we
going to jump through those hoops for one web page?  Nyet.

The list seems a bit short; did you look through the release notes for
items that seem to be security issues?  I suspect there are some that
don't have CVE names.

			regards, tom lane

---

From: Simon Riggs <[email-masked]>
Date: Sun, 27 Nov 2005 17:39:04 +0000

> http://magnus-master.pgadmin.org/support/security.

Some background to the statements made is probably required also.

We touched briefly upon what CVE is in various other posts on hackers.
The main CVE website is http://www.cve.mitre.org/

Maintaining CVE-compatible status is likely to be fairly important for
security risk management. It will also raise the profile of PostgreSQL
as secure software since CVE will list this project on their
compatibility page.

There are some basic requirements of CVE compatibility:
http://www.cve.mitre.org/compatible/ which are described in even more
detail here
http://www.cve.mitre.org/compatible/requirements.html

The link to CVE and the statement of support for CVE are part of those
requirements. Those are modelled after the Debian Security Information
page at http://www.us.debian.org/security/. That has nothing to do with
whether I am or am not a Debian supporter, its just a guide as to how we
might make statements to claim CVE-compatibility.

I'm happy to be the coordinator for CVE compatibility and fill out the
forms to apply for the external review. I'd also be happy if another
would like to claim this task.

Best Regards, Simon Riggs

---

From: Simon Riggs <[email-masked]>
Date: Sun, 27 Nov 2005 17:55:22 +0000

> Perhaps "all known security issues..."  The statement as made is

Agreed. I'm sure Magnus meant that.

> if it isn't trivial then it won't be fixed instantly anyway.)  

The wording was "typically", there is no "will do this" statement, so
its not a binding Service Level Agreement or anything.

In terms of what has happened in the last couple of years, I thought it
was a reasonable statement. It wasn't meant to be hype. If we can agree
a worthwhile and accurate statement I'd ask that we keep it; if we can't
then it should go.

> I'd lose

The line about our aim was part of the wording required (not exact, I
hasten to add) for CVE-compatibility...

> going to jump through those hoops for one web page?  Nyet.

There aren't that many hoops and I have volunteered to do the paperwork.

There isn't much else we need to do, apart from maintain the page.

If it gets more complex, then I'd agree the effort isn't worth it and
withdraw those comments.

> items that seem to be security issues?  I suspect there are some that

OK. I think we should publish this to -hackers and ask people to check
it before we put it up on the site.

---

From: Neil Conway <[email-masked]>
Date: Sun, 27 Nov 2005 17:35:54 -0500

> items that seem to be security issues?  I suspect there are some that

"Add checks for invalid field length in binary COPY (Tom)" in 7.4.3,
should probably be included.

If we're not going to describe issues with 7.2 and earlier releases
(which is probably reasonable), I think we should back off the claim
that "all known" security issues are listed. Personally I think we
shouldn't make the latter claim, anyway: for example, whether
COALESCE(NULL, NULL) dumping core (fixed in 8.0.3) is a "security issue"
is often in the eye of the beholder.

>From the page:

"Our approach covers fail-safe configuration options, a secure and
robust database server as well as good integration with other security
infrastructure software."

What "good integration with other security infrastructure" can PGDG
legitimately take credit for?

-Neil

---

From: Simon Riggs <[email-masked]>
Date: Mon, 28 Nov 2005 09:26:12 +0000

> legitimately take credit for?

Kerberos, OpenSSL and LDAP integration, plus with published details of
how to link in with MSAD.

"Good integration" is my subjective judgement only. If it isn't the
feeling of the team, then we can alter it.