Re: [HACKERS] What goes into the security doc?

With reference to my post to the "PostgreSQL Password Cracker" on
2003-01-02, I've promised to write a security document for the project.
Here it is, Sunday night, and I can't sleep. What better way to get there
than start this task...

My plan is to write this in very simple HTML. I will post the draft
document on my website and post the URL here from time to time for
feedback. Please make suggestions for content. So far, I will cover these
items:

- .pgpass (see
http://developer.postgresql.org/docs/postgres/libpq-files.html)
- local connections
- remote connections (recommending SSL)
- pg_hba (only in passing, most of that is at
http://www.postgresql.org/idocs/index.php?client-authentication.html)
- running the postmaster as a specific user

That doesn't sound like much. Surely you can think of something else to
add. Should I post this to another list for their views?

OK, that's done it. I'm ready for sleep now.

I'm not sure how adequately these topics are covered elsewhere, but you
should probably provide at least a pointer if not improved information:

* Should have a mention of the pgcrypto code in contrib.

* Brain hiccup, but isn't there some type of "password" datatype

* Explanation of problems/solutions of using md5 passwords inside
postgresql. this has tripped up a lot of people upgrading to 7.3

* possibly go into server resource issues and the pitfalls in giving
free form sql access to just anyone. (Think unconstrained join on all
tables in a database)

hth,

Robert Treat

On Mon, 2003-01-20 at 00:01, Dan Langille wrote:
> With reference to my post to the "PostgreSQL Password Cracker" on
> 2003-01-02, I've promised to write a security document for the project.
> Here it is, Sunday night, and I can't sleep. What better way to get there
> than start this task...
>
> My plan is to write this in very simple HTML. I will post the draft
> document on my website and post the URL here from time to time for
> feedback. Please make suggestions for content. So far, I will cover these
> items:
>
> - .pgpass (see
> http://developer.postgresql.org/docs/postgres/libpq-files.html)
> - local connections
> - remote connections (recommending SSL)
> - pg_hba (only in passing, most of that is at
> http://www.postgresql.org/idocs/index.php?client-authentication.html)
> - running the postmaster as a specific user
>
> That doesn't sound like much. Surely you can think of something else to
> add. Should I post this to another list for their views?
>
> OK, that's done it. I'm ready for sleep now.

Recommend always running "initdb -W" and setting all pg_hba entries to md5.

Chris

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org]On Behalf Of Robert Treat
> Sent: Tuesday, 21 January 2003 11:17 PM
> To: Dan Langille
> Cc: pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] What goes into the security doc?
>
>
> I'm not sure how adequately these topics are covered elsewhere, but you
> should probably provide at least a pointer if not improved information:
>
> * Should have a mention of the pgcrypto code in contrib.
>
> * Brain hiccup, but isn't there some type of "password" datatype
>
> * Explanation of problems/solutions of using md5 passwords inside
> postgresql. this has tripped up a lot of people upgrading to 7.3
>
> * possibly go into server resource issues and the pitfalls in giving
> free form sql access to just anyone. (Think unconstrained join on all
> tables in a database)
>
> hth,
>
> Robert Treat
>
> On Mon, 2003-01-20 at 00:01, Dan Langille wrote:
> > With reference to my post to the "PostgreSQL Password Cracker" on
> > 2003-01-02, I've promised to write a security document for the project.
> > Here it is, Sunday night, and I can't sleep. What better way
> to get there
> > than start this task...
> >
> > My plan is to write this in very simple HTML. I will post the draft
> > document on my website and post the URL here from time to time for
> > feedback. Please make suggestions for content. So far, I will
> cover these
> > items:
> >
> > - .pgpass (see
> > http://developer.postgresql.org/docs/postgres/libpq-files.html)
> > - local connections
> > - remote connections (recommending SSL)
> > - pg_hba (only in passing, most of that is at
> > http://www.postgresql.org/idocs/index.php?client-authentication.html)
> > - running the postmaster as a specific user
> >
> > That doesn't sound like much. Surely you can think of something else to
> > add. Should I post this to another list for their views?
> >
> > OK, that's done it. I'm ready for sleep now.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>

On 22 Jan 2003 at 13:29, Christopher Kings-Lynne wrote:

> Recommend always running "initdb -W" and setting all pg_hba entries to md5.

Thanks. I also encountered this item on IRC:

[09:26] <fede2> Guys, is there a problem with using /bin/true of
/bin/false as the shell of the postgres user? The docs only says
"adduser postgres" , witch will give postgres a nice shell.
[09:27] <fede2> I'm asking because the guys from Gentoo (thats a
distro FWIW), want to use either /bin/false of /bin/true as postgres'
shell.
[09:27] <dvl> fede2: it means you won't be able to become the
postgres user to run commands.
[09:27] <mmc_> ... to run SHELL commands.
[09:29] <fede2> dvl: Aldo it's not the same, one could use "su -c foo
postgres" to workarround it.
[09:30] <fede2> dvl: I was wondering if it had an even heavier
reason, besides that.
[09:34] <mmc_> fede2: tha manpage of su says, that -c args is treated
by the login shell !
[09:35] <fede2> mmc_: Hmm.. true. That makes it a heavy enough
reason. Thanks.
[09:35] * fede2 departs
--
Dan Langille : http://www.langille.org/

man su says (on Linux):

-s, --shell=SHELL
run SHELL if /etc/shells allows it

Illustration:

[adunsta:adunsta]$ su -s /bin/tcsh - -c 'ps -f $$'
Password:
UID PID PPID C STIME TTY STAT TIME CMD
root 10682 10681 0 10:34 pts/0 S 0:00 -tcsh -c ps -f $$
[adunsta:adunsta]$

So setting /bin/true as the login shell prevents real logins but doesn't
prevent running commands as the user via su, even from a login shell.

andrew

----- Original Message -----
From: "Dan Langille" <dan(at)langille(dot)org>
To: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Sent: Friday, January 24, 2003 10:00 AM
Subject: Re: [HACKERS] What goes into the security doc?

> On 22 Jan 2003 at 13:29, Christopher Kings-Lynne wrote:
>
> > Recommend always running "initdb -W" and setting all pg_hba entries to
md5.
>
> Thanks. I also encountered this item on IRC:
>
> [09:26] <fede2> Guys, is there a problem with using /bin/true of
> /bin/false as the shell of the postgres user? The docs only says
> "adduser postgres" , witch will give postgres a nice shell.
> [09:27] <fede2> I'm asking because the guys from Gentoo (thats a
> distro FWIW), want to use either /bin/false of /bin/true as postgres'
> shell.
> [09:27] <dvl> fede2: it means you won't be able to become the
> postgres user to run commands.
> [09:27] <mmc_> ... to run SHELL commands.
> [09:29] <fede2> dvl: Aldo it's not the same, one could use "su -c foo
> postgres" to workarround it.
> [09:30] <fede2> dvl: I was wondering if it had an even heavier
> reason, besides that.
> [09:34] <mmc_> fede2: tha manpage of su says, that -c args is treated
> by the login shell !
> [09:35] <fede2> mmc_: Hmm.. true. That makes it a heavy enough
> reason. Thanks.
> [09:35] * fede2 departs
> --
> Dan Langille : http://www.langille.org/
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org

Robert Treat wrote:
> I'm not sure how adequately these topics are covered elsewhere, but you
> should probably provide at least a pointer if not improved information:
>
> * Should have a mention of the pgcrypto code in contrib.
>
> * Brain hiccup, but isn't there some type of "password" datatype

It is in /contrib as chkpass:

Chkpass is a password type that is automatically checked and converted upon
entry. It is stored encrypted. To compare, simply compare agains a clear
text password and the comparison function will encrypt it before comparing.
It also returns an error if the code determines that the password is easily
crackable. This is currently a stub that does nothing.

I haven't worried about making this type indexable. I doubt that anyone
would ever need to sort a file in order of encrypted password.

If you precede the string with a colon, the encryption and checking are
skipped so that you can enter existing passwords into the field.

On output, a colon is prepended. This makes it possible to dump and reload
passwords without re-encrypting them. If you want the password (encrypted)
without the colon then use the raw() function. This allows you to use the
type with things like Apache's Auth_PostgreSQL module.

D'Arcy J.M. Cain
darcy(at)druid(dot)net

The document is a good idea, and the initdb -W item is good too!

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Now that we are in beta, does someone want to tackle a "security"
section in the docs?

---------------------------------------------------------------------------

Dan Langille wrote:
> With reference to my post to the "PostgreSQL Password Cracker" on
> 2003-01-02, I've promised to write a security document for the project.
> Here it is, Sunday night, and I can't sleep. What better way to get there
> than start this task...
>
> My plan is to write this in very simple HTML. I will post the draft
> document on my website and post the URL here from time to time for
> feedback. Please make suggestions for content. So far, I will cover these
> items:
>
> - .pgpass (see
> http://developer.postgresql.org/docs/postgres/libpq-files.html)
> - local connections
> - remote connections (recommending SSL)
> - pg_hba (only in passing, most of that is at
> http://www.postgresql.org/idocs/index.php?client-authentication.html)
> - running the postmaster as a specific user
>
> That doesn't sound like much. Surely you can think of something else to
> add. Should I post this to another list for their views?
>
> OK, that's done it. I'm ready for sleep now.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Given I'm the smartass that volunteered in the first place, perhaps I
should complete what I started.

I work well with a deadline. When do you want this done?

On 16 Aug 2003 at 12:41, Bruce Momjian wrote:

> Now that we are in beta, does someone want to tackle a "security"
> section in the docs?
>
>
> ---------------------------------------------------------------------------
>
> Dan Langille wrote:
> > With reference to my post to the "PostgreSQL Password Cracker" on
> > 2003-01-02, I've promised to write a security document for the project.
> > Here it is, Sunday night, and I can't sleep. What better way to get there
> > than start this task...
> >
> > My plan is to write this in very simple HTML. I will post the draft
> > document on my website and post the URL here from time to time for
> > feedback. Please make suggestions for content. So far, I will cover these
> > items:
> >
> > - .pgpass (see
> > http://developer.postgresql.org/docs/postgres/libpq-files.html)
> > - local connections
> > - remote connections (recommending SSL)
> > - pg_hba (only in passing, most of that is at
> > http://www.postgresql.org/idocs/index.php?client-authentication.html)
> > - running the postmaster as a specific user
> >
> > That doesn't sound like much. Surely you can think of something else to
> > add. Should I post this to another list for their views?
> >
> > OK, that's done it. I'm ready for sleep now.
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/users-lounge/docs/faq.html
> >
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>

--
Dan Langille : http://www.langille.org/

I would say any time before 7.4 final, which should be in 4-6 weeks.

---------------------------------------------------------------------------

Dan Langille wrote:
> Given I'm the smartass that volunteered in the first place, perhaps I
> should complete what I started.
>
> I work well with a deadline. When do you want this done?
>
> On 16 Aug 2003 at 12:41, Bruce Momjian wrote:
>
> > Now that we are in beta, does someone want to tackle a "security"
> > section in the docs?
> >
> >
> > ---------------------------------------------------------------------------
> >
> > Dan Langille wrote:
> > > With reference to my post to the "PostgreSQL Password Cracker" on
> > > 2003-01-02, I've promised to write a security document for the project.
> > > Here it is, Sunday night, and I can't sleep. What better way to get there
> > > than start this task...
> > >
> > > My plan is to write this in very simple HTML. I will post the draft
> > > document on my website and post the URL here from time to time for
> > > feedback. Please make suggestions for content. So far, I will cover these
> > > items:
> > >
> > > - .pgpass (see
> > > http://developer.postgresql.org/docs/postgres/libpq-files.html)
> > > - local connections
> > > - remote connections (recommending SSL)
> > > - pg_hba (only in passing, most of that is at
> > > http://www.postgresql.org/idocs/index.php?client-authentication.html)
> > > - running the postmaster as a specific user
> > >
> > > That doesn't sound like much. Surely you can think of something else to
> > > add. Should I post this to another list for their views?
> > >
> > > OK, that's done it. I'm ready for sleep now.
> > >
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 5: Have you checked our extensive FAQ?
> > >
> > > http://www.postgresql.org/users-lounge/docs/faq.html
> > >
> >
> > --
> > Bruce Momjian | http://candle.pha.pa.us
> > pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> > + If your life is a hard drive, | 13 Roberts Road
> > + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> >
>
>
> --
> Dan Langille : http://www.langille.org/
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian writes:

> Now that we are in beta, does someone want to tackle a "security"
> section in the docs?

IMO, security shouldn't be a section, it should be a recurring theme
throughout all documentation material.

--
Peter Eisentraut peter_e(at)gmx(dot)net

On 19 Aug 2003 at 10:18, Peter Eisentraut wrote:

> Bruce Momjian writes:
>
> > Now that we are in beta, does someone want to tackle a "security"
> > section in the docs?
>
> IMO, security shouldn't be a section, it should be a recurring theme
> throughout all documentation material.

Do you think the existing docs are inadequete in this regard? If so,
in what areas are they insufficient? What changes do you recommend?

FWIW, having a theme is a great idea. Please let us know of any
changes you see necessary. But I, and others much wiser than I am,
think a section where the admin can read up on the important stuff is
essential.

If you were new to PostgreSQL, would you rather string together
information from all over the documentation or would you rather have
a concise overview of Things You Need To Know(tm)?

As always, patches are requested.
--
Dan Langille : http://www.langille.org/

I've started. I'm wondering how much we need to cover here and how
much can be delegated to other sections of the documentation. Before
I get very far into this, I want to get some ideas as to what we
need.

This is what I have so far:
http://www.freebsddiary.org/tmp/PostgreSQL-security.txt

cheers

On 16 Aug 2003 at 12:41, Bruce Momjian wrote:

>
> Now that we are in beta, does someone want to tackle a "security"
> section in the docs?
>
>
> ---------------------------------------------------------------------------
>
> Dan Langille wrote:
> > With reference to my post to the "PostgreSQL Password Cracker" on
> > 2003-01-02, I've promised to write a security document for the project.
> > Here it is, Sunday night, and I can't sleep. What better way to get there
> > than start this task...
> >
> > My plan is to write this in very simple HTML. I will post the draft
> > document on my website and post the URL here from time to time for
> > feedback. Please make suggestions for content. So far, I will cover these
> > items:
> >
> > - .pgpass (see
> > http://developer.postgresql.org/docs/postgres/libpq-files.html)
> > - local connections
> > - remote connections (recommending SSL)
> > - pg_hba (only in passing, most of that is at
> > http://www.postgresql.org/idocs/index.php?client-authentication.html)
> > - running the postmaster as a specific user
> >
> > That doesn't sound like much. Surely you can think of something else to
> > add. Should I post this to another list for their views?
> >
> > OK, that's done it. I'm ready for sleep now.
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/users-lounge/docs/faq.html
> >
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>

--
Dan Langille : http://www.langille.org/

Dan Langille writes:

> I've started. I'm wondering how much we need to cover here and how
> much can be delegated to other sections of the documentation. Before
> I get very far into this, I want to get some ideas as to what we
> need.

If you intend this to go into the main documentation, then I think we
don't need anything, because everything is already documented in its
proper place. What you wrote is basically just a summary of various
system aspects that might have to do with that vague word "security",
together with pointers to the places where they are documented (which
reinforces my point). Perhaps a "howto" format that you can post on
techdocs might be more appropriate for you.

--
Peter Eisentraut peter_e(at)gmx(dot)net

On 30 Aug 2003 at 16:15, Peter Eisentraut wrote:

> Dan Langille writes:
>
> > I've started. I'm wondering how much we need to cover here and how
> > much can be delegated to other sections of the documentation. Before
> > I get very far into this, I want to get some ideas as to what we
> > need.
>
> If you intend this to go into the main documentation, then I think we
> don't need anything, because everything is already documented in its
> proper place.

It has already been decided that we need something. Hence the
request for someone to write it and my start on the task.

> What you wrote is basically just a summary of various
> system aspects that might have to do with that vague word "security",
> together with pointers to the places where they are documented (which
> reinforces my point).

Your point being that we don't need anything more than we already
have? That conflicts with what has already been decided.

> Perhaps a "howto" format that you can post on
> techdocs might be more appropriate for you.

I'm not sure what you mean by "for you".

--
Dan Langille : http://www.langille.org/

Dan Langille writes:

> It has already been decided that we need something.

Please point me to where this has been decided.

--
Peter Eisentraut peter_e(at)gmx(dot)net

On 30 Aug 2003 at 17:37, Peter Eisentraut wrote:

> Dan Langille writes:
>
> > It has already been decided that we need something.
>
> Please point me to where this has been decided.

I'm sure you can google as well I can can. The original message in
this thread referred to "PostgreSQL Password Cracker" posted on 2003-
01-02. You could also search for the subject of this message. When
you find those you'll see that such a section was suggested. I took
up the task, suggested some content. Then it lingered and was
brought up again recently. Your objections are the first.

I can't see why you, or anyone for that matter, can possibly object
to a section titled security which points to the relevent components
and parts within the documentation. As previously stated, what I have
posted is a starting point.

You aren't being asked to do the work. Why do you care if someone
else does it? You may not need such documentation, but it will be
useful to many.
--
Dan Langille : http://www.langille.org/

Dan Langille wrote:
> On 30 Aug 2003 at 17:37, Peter Eisentraut wrote:
>
> > Dan Langille writes:
> >
> > > It has already been decided that we need something.
> >
> > Please point me to where this has been decided.
>
> I'm sure you can google as well I can can. The original message in
> this thread referred to "PostgreSQL Password Cracker" posted on 2003-
> 01-02. You could also search for the subject of this message. When
> you find those you'll see that such a section was suggested. I took
> up the task, suggested some content. Then it lingered and was
> brought up again recently. Your objections are the first.
>
> I can't see why you, or anyone for that matter, can possibly object
> to a section titled security which points to the relevent components
> and parts within the documentation. As previously stated, what I have
> posted is a starting point.
>
> You aren't being asked to do the work. Why do you care if someone
> else does it? You may not need such documentation, but it will be
> useful to many.

I don't think we "decided" to add it, but no one has objected to the
idea, except Peter recently. Does it make sense to have a security
overview section in the documentation?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I don't think we "decided" to add it, but no one has objected to the
> idea, except Peter recently. Does it make sense to have a security
> overview section in the documentation?

I think it does.

As I think Peter is trying to point out, you could almost get the same
result just by having a fat index entry under "security", but I think
people are more likely to notice a chapter or section in the Admin Guide
with such a title. Also, once we have such a chapter, we might find it
reads more naturally to move some of the existing discussions into it,
leaving only a cross-reference where the material is now.

regards, tom lane

Tom Lane writes:

> As I think Peter is trying to point out, you could almost get the same
> result just by having a fat index entry under "security", but I think
> people are more likely to notice a chapter or section in the Admin Guide
> with such a title. Also, once we have such a chapter, we might find it
> reads more naturally to move some of the existing discussions into it,
> leaving only a cross-reference where the material is now.

These are the topics that Dan has identified so far:

file security
database users and privileges
client authentication
libpq password files
external libraries

It makes no sense to put all these topics into one chapter, because they
have nothing in common (except "security"): they apply in different stages
of PostgreSQL use, they are managed by different programs and
environments, and they affect different people.

From that point of view, we already have security documentation:

The chapter "Server Run-time Environment" (currently ch.16) covers
security aspects for system administrators when setting up a server.

The chapter "Database Users and Privileges" (ch. 17) covers security
aspects for database administrators on the SQL level.

The chapter "Client Authentication" (ch. 18) covers security aspects
covers security aspects for database/system administrators with file
system access (depends on local policies who does that).

The section "libpq"/"The Password File" covers one particular aspect of
security of libpq applications. (There are certainly more interesting
security aspects with libpq applications. The password file is pretty
uninteresting, because if you don't secure it it's ignored anyway.)

Note that chapters 17 and 18 are exclusively dedicated to security -- you
can't even claim to miss it in the other material, and unless you don't
know what "privileges" and "authentication" are, you can't even miss them
in the table of contents. And if you start reading chapter 16, the first
two sections are all about securing the server.

The issue that started this was that there was not enough documentation
about choosing good passwords and preferably not using passwords over
non-SSL connections over public networks. I agree that this could be
improved, and it could be done by regrouping some of the above material.
But we don't need a section that just points to other sections, because
that doesn't improve the substance of the material. On the contrary, it
is known to confuse and annoy readers.

--
Peter Eisentraut peter_e(at)gmx(dot)net

On 30 Aug 2003 at 17:50, Tom Lane wrote:

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I don't think we "decided" to add it, but no one has objected to the
> > idea, except Peter recently. Does it make sense to have a security
> > overview section in the documentation?
>
> I think it does.
>
> As I think Peter is trying to point out, you could almost get the same
> result just by having a fat index entry under "security", but I think
> people are more likely to notice a chapter or section in the Admin Guide
> with such a title. Also, once we have such a chapter, we might find it
> reads more naturally to move some of the existing discussions into it,
> leaving only a cross-reference where the material is now.

So do we want this work or not?
--
Dan Langille : http://www.langille.org/