Return-Path: pg_adm@postgres.berkeley.edu
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA16812; Wed, 6 May 92 08:45:46 -0700
Message-Id: <9205061545.AA16812@postgres.Berkeley.EDU>
From: mao@olympus.cs.berkeley.edu (Mike Olson)
Subject: Re: Using Postgres from Unix and security
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: Your message of Wed, 06 May 92 14:34:44 +0100.
             <9205061235.AA15522@postgres.Berkeley.EDU> 
Date: Wed, 06 May 92 08:49:00 PDT

In message <9205061235.AA15522@postgres.Berkeley.EDU> you write:

> I have done this (at least to some extent).  I have modified the
> postmaster so that it only accepts connections from my subnet and only
> connections from privileged tcp ports.  I have modified the monitor so
> that it is setuid root, uses a privileged port, and calls getuid(2) and
> getpwent(3) to determine the user name to send to the postmaster.  In
> this way the user name that the postmaster receives will be correct.
> This was easy so I don't really know why somebody has not already done
> it.  Perhaps I have missed something obvious.  Once I am sure that I am
> not being naive I will post the patches.

restricting connections to those originating on your subnet certainly
reduces the number of people who can mount an attack on your database,
but the approach you describe doesn't solve the security problem.  i
can write a program that does tcp socket operations and obeys the postgres
frontend/backend protocol (easy to do since we distribute source code).
i can have this program send any user name to the postmaster that i want.
the postmaster can't authenticate data coming at it over a network.

you've increased the sophistication required to break into the database
system by a little bit.  denying connections to off-site networks is the
most effective of your tricks, since it means that attackers must at least
have access to one of your local machines.  even this is subvertible, but
breakins from off-site require substantially more work than before.

the right answer is to use kerberos and set up trusted channels between
the postmaster and the libpq process.  there have been enough complaints
that we'll probably do this sometime this summer.

					mike olson
					postgres research group
					uc berkeley
					mao@cs.berkeley.edu