Обсуждение: Re: New pg_pwd patch and stuff
> 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
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
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
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
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
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
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
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