>         Fork off the postgres process first, then authenticate inside of
> there...which would get rid of the problem with pg_user itself being a
> text file vs a relation...no?

Yes, yes, yes.  This is how authentication should be done (for HBA, etc.)
Furthermore, we could reduce the footprint of the postmaster drastically.  It
would only need to accept a socket connection and fork the backend.  This
scenario would also allow the postmaster to be run as the root user.  Good
things could only come of this method.

The only reason I put my authentication scheme where it is, is that all the
other authentication schemes take place in the postmaster, and to work things
properly, use of my scheme (checking to see if there is a password or not) must
come first.

Todd A. Brandys
brandys@eng3.hep.uiuc.edu


Thu, 15 Jan 1998 14:31:37 -0600
todd brandys <brandys@eng3.hep.uiuc.edu>
Re: New pg_pwd patch and stuff
todd brandys wrote:
> 
> >         Fork off the postgres process first, then authenticate inside of
> > there...which would get rid of the problem with pg_user itself being a
> > text file vs a relation...no?
> 
> Yes, yes, yes.  This is how authentication should be done (for HBA, etc.)

No, no, no! For security reasons, you can't fork (and exec)
unauthenticated processes. Especially HBA authentication should be done
to consume as low resources as possbile. Otherwise you open a giant door
for so infamously called Denial of Service attacks. Afterwards, every
hacker will know that to bring your system running postgres to it's
knees he just have to try to connect to 5432 port very frequently. "OK",
you might say, "I have this firewall". "OK", I say, "so what's that HBA
for?".

So it's the postmaster's role to deny as much connections as possible.
Unless we speak of non-execing postgres childs?

Mike

-- 
WWW: http://www.lodz.pdi.net/~mimo  tel: Int. Acc. Code + 48 42 148340
add: Michal Mosiewicz  *  Bugaj 66 m.54 *  95-200 Pabianice  *  POLAND

Fri, 16 Jan 1998 02:35:38 +0000
"Micha��� Mosiewicz" <mimo@lodz.pdi.net>
Re: [HACKERS] Re: New pg_pwd patch and stuff
On Fri, 16 Jan 1998, Micha3 Mosiewicz wrote:

> No, no, no! For security reasons, you can't fork (and exec)
> unauthenticated processes. Especially HBA authentication should be done
> to consume as low resources as possbile. Otherwise you open a giant door
> for so infamously called Denial of Service attacks. Afterwards, every
> hacker will know that to bring your system running postgres to it's
> knees he just have to try to connect to 5432 port very frequently. "OK",
> you might say, "I have this firewall". "OK", I say, "so what's that HBA
> for?".
> 
> So it's the postmaster's role to deny as much connections as possible.
> Unless we speak of non-execing postgres childs?

	Hrmmmm...i don't quite agree with this.  postmaster can handle one 
connection at a time, and then has to pass it off to the postgres backend
process...DoS attacks are easier now then by forking before HBA.  I just have
to continuously open a connection to port 5432...so, while postmaster is
handling that connection, checking HBA, checking a password...no other new 
connections can  happen.  Can't think of a stronger DoS then that...? :)

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Fri, 16 Jan 1998 00:11:46 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Re: New pg_pwd patch and stuff
The Hermit Hacker wrote:
> 
> On Fri, 16 Jan 1998, Micha3 Mosiewicz wrote:
> 
> > No, no, no! For security reasons, you can't fork (and exec)
> > unauthenticated processes. Especially HBA authentication should be done
> > to consume as low resources as possbile. Otherwise you open a giant door
> > for so infamously called Denial of Service attacks. Afterwards, every
> > hacker will know that to bring your system running postgres to it's
> > knees he just have to try to connect to 5432 port very frequently. "OK",
> > you might say, "I have this firewall". "OK", I say, "so what's that HBA
> > for?".
> >
> > So it's the postmaster's role to deny as much connections as possible.
> > Unless we speak of non-execing postgres childs?
> 
>         Hrmmmm...i don't quite agree with this.  postmaster can handle one
> connection at a time, and then has to pass it off to the postgres backend
> process...DoS attacks are easier now then by forking before HBA.  I just have
> to continuously open a connection to port 5432...so, while postmaster is
> handling that connection, checking HBA, checking a password...no other new
> connections can  happen.  Can't think of a stronger DoS then that...? :)

I think Micha is right.  The postmaster can handle multiple connections
as the read of the startup packet is done a fragment at a time without
blocking so there is no DoS problem until the postmaster runs out of
sockets.  I think this is less of a problem than loads of
unauthenticated, resource hungry backends forked by the postmaster.

In changing the authentication methods for 6.3 I've had to add the
ability for the postmaster to do non-blocking writes as well as reads so
that a two-way (non-blocking) dialog can take place between frontend and
postmaster.

Having said that, I won't fix (for 6.3 anyway) other parts of the
postmaster that do blocked I/O - the ident lookup in particular. 
However, it is at least under the control of the DBA whether or not
ident is used.

Phil

Fri, 16 Jan 1998 19:45:14 +0000
Phil Thompson <phil@river-bank.demon.co.uk>
Re: [HACKERS] Re: New pg_pwd patch and stuff
The Hermit Hacker wrote:

>         Hrmmmm...i don't quite agree with this.  postmaster can handle one
> connection at a time, and then has to pass it off to the postgres backend
> process...DoS attacks are easier now then by forking before HBA.  I just have

Forking is not so bad... but isn't there any exec also? And of course
it's a difference if your machine is overloaded by processes or if it's
only one service that doesn't respond becouse the access-controling code
is disabled.

Second question... if we speak only about forking postmaster, or it's
about forking-execing-opening files-reading-etc stuff? If it's only
fork, I would totally agree with you, otherwise I'm not sure which is
worse... 

Mike

-- 
WWW: http://www.lodz.pdi.net/~mimo  tel: Int. Acc. Code + 48 42 148340
add: Michal Mosiewicz  *  Bugaj 66 m.54 *  95-200 Pabianice  *  POLAND


Sun, 18 Jan 1998 03:39:45 +0000
"Micha3 Mosiewicz" <mimo@lodz.pdi.net>
Re: [HACKERS] Re: New pg_pwd patch and stuff


On Fri, 16 Jan 1998, Phil Thompson wrote:

> The Hermit Hacker wrote:
> > 
> > On Fri, 16 Jan 1998, Micha3 Mosiewicz wrote:
> > 
> > > No, no, no! For security reasons, you can't fork (and exec)
> > > unauthenticated processes. Especially HBA authentication should be done
> > > to consume as low resources as possbile. Otherwise you open a giant door
> > > for so infamously called Denial of Service attacks. Afterwards, every
> > > hacker will know that to bring your system running postgres to it's
> > > knees he just have to try to connect to 5432 port very frequently. "OK",
> > > you might say, "I have this firewall". "OK", I say, "so what's that HBA
> > > for?".
> > >
> > > So it's the postmaster's role to deny as much connections as possible.
> > > Unless we speak of non-execing postgres childs?
> > 
> >         Hrmmmm...i don't quite agree with this.  postmaster can handle one
> > connection at a time, and then has to pass it off to the postgres backend
> > process...DoS attacks are easier now then by forking before HBA.  I just have
> > to continuously open a connection to port 5432...so, while postmaster is
> > handling that connection, checking HBA, checking a password...no other new
> > connections can  happen.  Can't think of a stronger DoS then that...? :)
> 
> I think Micha is right.  The postmaster can handle multiple connections
> as the read of the startup packet is done a fragment at a time without
> blocking so there is no DoS problem until the postmaster runs out of
> sockets.  I think this is less of a problem than loads of
> unauthenticated, resource hungry backends forked by the postmaster.
> 
> In changing the authentication methods for 6.3 I've had to add the
> ability for the postmaster to do non-blocking writes as well as reads so
> that a two-way (non-blocking) dialog can take place between frontend and
> postmaster.
> 
> Having said that, I won't fix (for 6.3 anyway) other parts of the
> postmaster that do blocked I/O - the ident lookup in particular. 
> However, it is at least under the control of the DBA whether or not
> ident is used.
> 
> Phil
> 

One way or another PostgreSQL is subject to attack.  If we do continue on 
with postmaster doing authentication, then the postmaster should be made 
capable of performing queries against the system catalog.  This would 
allow HBA to be incorporated into the system catalog (pg_user or 
whatever).  Why would we do this?  It will make PostgreSQL easier to 
administer.  The user will not have to edit files to make a change.  HBA's
characteristics could be partially handled by adding a:

FROM (<host1> | <group1>) ... [, (<hostn> | <groupn>)]

clause to the 'CREATE USER' statement.  Right now the only way this could be
achieved would be to pass authentication down to the backend processes, 
as the postmaster can not execute SQL statements.

Todd A. Brandys
brandys@eng3.hep.uiuc.edu


Sun, 18 Jan 1998 15:47:30 -0600 (CST)
todd brandys <brandys@eng3.hep.uiuc.edu>
Re: [HACKERS] Re: New pg_pwd patch and stuff
  So, if postmaster can't access the system tables for authentication
purposes, why not have one child forked, connected to the main 
postmaster process via some IPC mechanism, whose only purpose
in life it is to answer SQL-queries for postmaster.

	mjl


Mon, 19 Jan 1998 04:18:34 +0100 (MET)
"Martin J. Laubach" <mjl@emsi.priv.at>
Re: [HACKERS] Re: New pg_pwd patch and stuff


On Mon, 19 Jan 1998, Martin J. Laubach wrote:

>   So, if postmaster can't access the system tables for authentication
> purposes, why not have one child forked, connected to the main 
> postmaster process via some IPC mechanism, whose only purpose
> in life it is to answer SQL-queries for postmaster.
> 
> 	mjl
> 
> 

I would have to say "footprint".  All the code for the backend has been 
incorporated into the postmaster.  The postmaster is nothing more than a
backend run with some special command line options.  The postgres executable
is over 1 MB large and is a static executable.  This is quite a bit of
(virtual) memory.   I realize that memory is cheap these days, but to 
have all the backend code included in with the postmaster and not have it 
useable is a waste of resources.  To then have a second instance running 
would take more resources.

If we must maintain user authorization in the postmaster, then I believe 
it would be best to strip this code from the postgres executable to 
create a postmaster with a smaller footprint.  Furthermore, the postmaster
should be made capable of performing heapscans, so that it could at least
view the data in the system catalog.  Then all the data needed for each 
authentication method (or a single method if we incorporated the best 
aspects of each method into one super authentication method), could be 
stored in the system catalog.  This information could then be managed by the
CREATE/ALTER USER statements, which would alleviate the need to edit flat 
files for system configuration.

Todd A. Brandys
brandys@eng3.hep.uiuc.edu


Tue, 20 Jan 1998 12:10:23 -0600 (CST)
todd brandys <brandys@eng3.hep.uiuc.edu>
Re: [HACKERS] Re: New pg_pwd patch and stuff