Thread: 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@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Robert Treat > Sent: Tuesday, 21 January 2003 11:17 PM > To: Dan Langille > Cc: pgsql-hackers@postgresql.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@langille.org>
To: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Cc: <pgsql-hackers@postgresql.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 uponentry. It is storedencrypted. To compare, simply compare agains a cleartext password and the comparison function will encrypt it beforecomparing.It also returns an error if the code determines that the password is easilycrackable. This is currentlya stub that does nothing.I haven't worried about making this type indexable. I doubt that anyonewould ever needto sort a file in order of encrypted password.If you precede the string with a colon, the encryption and checking areskippedso that you can enter existing passwords into the field.On output, a colon is prepended. This makes it possibleto dump and reloadpasswords without re-encrypting them. If you want the password (encrypted)without the colon thenuse the raw() function. This allows you to use thetype with things like Apache's Auth_PostgreSQL module.D'Arcy J.M.Caindarcy@druid.net The document is a good idea, and the initdb -W item is good too! -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073