Thread: Re: PgSQL not as Administrator - probs on w

Steve Tibbett wrote:
> It is normal on Windows for users to have admin rights on the local
> system.  As much as this needs to be changed, you're not going to
> change it.  If you insist on not running on an account with admin
> rights, you're just going to frustrate users
>
> You could say "Windows is inherently insecure; refusing to run".  That
> would make the port much simpler.  :)
>
> A warning is appropriate I think.. but refusing to run is going
> overboard.  Just my two cents.

I disagree completely.  Opening a tcp/ip server with this level of
complexity for root access is a recipe for disaster.  Wait until an
exploit pops up and hundreds of win32 boxes get rooted.  This would be a
huge embarrassment and would be awful press.  Do you really want to
allow for this scenario?

Merlin

Merlin Moncure wrote:
> Steve Tibbett wrote:
>>
>> It is normal on Windows for users to have admin rights on the local
>> system.  As much as this needs to be changed, you're not going to
>> change it.  If you insist on not running on an account with admin
>> rights, you're just going to frustrate users
>>
>> You could say "Windows is inherently insecure; refusing to run".  That
>> would make the port much simpler.  :)
>>
>> A warning is appropriate I think.. but refusing to run is going
>> overboard.  Just my two cents.
>
> I disagree completely.  Opening a tcp/ip server with this level of
> complexity for root access is a recipe for disaster.  Wait until an
> exploit pops up and hundreds of win32 boxes get rooted.  This would be a
> huge embarrassment and would be awful press.  Do you really want to
> allow for this scenario?

I'm not sure I understand the problem. Doesn't an administrative
user have sufficient priviledges to 'do the right thing' and
create a user for the PostgreSQL service? Isn't it just a matter
of wrapping the necessary commands in batchfiles with a
teletubbies icon so that the user doesn't even notice PostgreSQL
is running under another account?

The only problem I foresee is that users might find doing the
right thing too complicated. Lets focus on making it easier.

Jochem

Merlin Moncure said:
> Steve Tibbett wrote:
>> It is normal on Windows for users to have admin rights on the local
>> system.  As much as this needs to be changed, you're not going to
>> change it.  If you insist on not running on an account with admin
>> rights, you're just going to frustrate users
>>
>> You could say "Windows is inherently insecure; refusing to run".  That
>> would make the port much simpler.  :)
>>
>> A warning is appropriate I think.. but refusing to run is going
>> overboard.  Just my two cents.
>
> I disagree completely.  Opening a tcp/ip server with this level of
> complexity for root access is a recipe for disaster.  Wait until an
> exploit pops up and hundreds of win32 boxes get rooted.  This would be
> a huge embarrassment and would be awful press.  Do you really want to
> allow for this scenario?
>

One compromise might be that we refuse to run with elevated privs on Windows
if configured to listen on more than localhost. Then developers with admin
privs could play happily, but server admins would need to do the Right Thing
(tm). Of course, if another local service could be induced to do bad things
via postgres that would be no protection, but at least we would not be the
primary attack vector.

cheers

andrew

On 9 Jul 2004 at 11:02, Andrew Dunstan wrote:

> >
> > I disagree completely.  Opening a tcp/ip server with this level of
> > complexity for root access is a recipe for disaster.  Wait until an
> > exploit pops up and hundreds of win32 boxes get rooted.  This would be
> > a huge embarrassment and would be awful press.  Do you really want to
> > allow for this scenario?
> >
>
> One compromise might be that we refuse to run with elevated privs on Windows
> if configured to listen on more than localhost. Then developers with admin
> privs could play happily, but server admins would need to do the Right Thing
> (tm). Of course, if another local service could be induced to do bad things
> via postgres that would be no protection, but at least we would not be the
> primary attack vector.
>

If the installer is going to create a non-priv user anyway, why not store that
username somewhere (environment/registry etc.) then if the user tries to
run as administrator just issue a message to the effect that postmaster
needs to start as user xxx (e.g. postgres) and prompt the user for the
postgres password. The postmaster should be able to then impersonate the
postgres user or launch the "runas" command/service with the appropriate
parameters. In this way the user can still be administrator, but run
postmaster in a command window with the minimum of fuss.

Even diehard Windows users shouldn't complain too much about that.

The only downside is that this may not work on older NT systems.  Most of
the NT4 machines around will be server type machines anyway, not
interactive development type stuff. Postmaster should still refuse to run (as
admin) on this small minority of machines for now. We may eventually find
a way around that too.

Feasible?

Cheers,
Gary.

Andrew Dunstan wrote:

>Merlin Moncure said:
>
>
>>Steve Tibbett wrote:
>>
>>
>>>It is normal on Windows for users to have admin rights on the local
>>>system.  As much as this needs to be changed, you're not going to
>>>change it.  If you insist on not running on an account with admin
>>>rights, you're just going to frustrate users
>>>
>>>You could say "Windows is inherently insecure; refusing to run".  That
>>>would make the port much simpler.  :)
>>>
>>>A warning is appropriate I think.. but refusing to run is going
>>>overboard.  Just my two cents.
>>>
>>>
>>I disagree completely.  Opening a tcp/ip server with this level of
>>complexity for root access is a recipe for disaster.  Wait until an
>>exploit pops up and hundreds of win32 boxes get rooted.  This would be
>>a huge embarrassment and would be awful press.  Do you really want to
>>allow for this scenario?
>>
>>
>>
>
>One compromise might be that we refuse to run with elevated privs on Windows
>if configured to listen on more than localhost. Then developers with admin
>privs could play happily, but server admins would need to do the Right Thing
>(tm). Of course, if another local service could be induced to do bad things
>via postgres that would be no protection, but at least we would not be the
>primary attack vector.
>
>
>
A sql injection vulnerability in an application could still compromise
the local machine.  It's better to be safe than sorry.

 >One compromise might be that we refuse to run with elevated privs on
Windows
 >if configured to listen on more than localhost. Then developers with admin
 >privs could play happily, but server admins would need to do the Right
Thing
 >(tm). Of course, if another local service could be induced to do bad
things
 >via postgres that would be no protection, but at least we would not be the
 >primary attack vector.

Andrew,

I got the same problem with postgres and Adminsitrator Privs on Windows,
and know that Admin on Windows is "quite usual".

I also thought of that solution - to recommend postgresql just to listen
to localhost when running with admin privs.

But that is of no use:

1) Usual webserver, PHP or whatever, postgresql on same host. Some flaky
php design, and you can attack via SQL-Spoofing with the requests coming
from localhost

2) somebody got shell access via some other security hole in IIS or
whatever. Now he could use local postgresql for privilege elevation.

I'm also not very lucky about postgresql not running with Admin privs,
but after thinking and listening to the arguments, I would recommend
that we focus our energies to make it totally easy to "automagically do
the right thing", maybe even "if run as Admin, create Postgresql user
with no rights and run as Postgres"

Harald