Thread

1. Re: New pg_pwd patch and stuff

   todd brandys <brandys@eng3.hep.uiuc.edu> — 1998-01-15T20:31:37Z

   >         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
   
   
   

2. Re: [HACKERS] Re: New pg_pwd patch and stuff

   Micha3 Mosiewicz <mimo@lodz.pdi.net> — 1998-01-16T02:35:38Z

   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
   
   

3. Re: [HACKERS] Re: New pg_pwd patch and stuff

   Marc G. Fournier <scrappy@hub.org> — 1998-01-16T04:11:46Z

   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 
   
   
   

4. Re: [HACKERS] Re: New pg_pwd patch and stuff

   Phil Thompson <phil@river-bank.demon.co.uk> — 1998-01-16T19:45:14Z

   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
   
   

5. Re: [HACKERS] Re: New pg_pwd patch and stuff

   Micha3 Mosiewicz <mimo@lodz.pdi.net> — 1998-01-18T03:39:45Z

   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
   
   
   

6. Re: [HACKERS] Re: New pg_pwd patch and stuff

   todd brandys <brandys@eng3.hep.uiuc.edu> — 1998-01-18T21:47:30Z

   
   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
   
   
   

7. Re: [HACKERS] Re: New pg_pwd patch and stuff

   Martin J. Laubach <mjl@emsi.priv.at> — 1998-01-19T03:18:34Z

     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
   
   
   

8. Re: [HACKERS] Re: New pg_pwd patch and stuff

   todd brandys <brandys@eng3.hep.uiuc.edu> — 1998-01-20T18:10:23Z

   
   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