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

From: todd brandys <brandys(at)eng3(dot)hep(dot)uiuc(dot)edu>
To: Phil Thompson <phil(at)river-bank(dot)demon(dot)co(dot)uk>
Cc: The Hermit Hacker <scrappy(at)hub(dot)org>, Micha3 Mosiewicz <mimo(at)lodz(dot)pdi(dot)net>, hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Re: New pg_pwd patch and stuff
Date: 1998-01-18 21:47:30
Message-ID: Pine.3.89.9801181517.A1160-0100000@eng3.hep.uiuc.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)eng3(dot)hep(dot)uiuc(dot)edu

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1998-01-19 02:21:02 Re: [HACKERS] Re: New pg_pwd patch and stuff
Previous Message todd brandys 1998-01-18 21:29:50 Re: [HACKERS] Re: New pg_pwd patch and stuff