Обсуждение: Why does Postgres need the /bin/sh?

Hey guys... second post of the day.  If you read my last post about
Postgres 7.2.1 segfaulting on Slackware 8.0, you noted I am trying to
chroot Postgres.  Unfortunately, my chrooted postgres cannot create
databases due to a 'system' call, which runs '/bin/sh'.  Having the shell
in my chroot kinda defeats part of why I chrooted in the first place.

I upgraded to 7.2.1, hoping this routine was changed, but it hasn't.

While, IMHO, the safest way to do this would be to code the cp and rm code
internally, I have patched my copy to do a fork and execl to call the cp
and rm programs directly (and placed /bin/cp and /bin/rm in the chroot
jail) as a quick fix... I feel it gives a bit more security.

Can anyone tell me if there is any inherently bad side effects to this?
Or why the "system" call is necessary?

                    ----Steve
Stephen Amadei
Dandy.NET!  CTO
Atlantic City, NJ

Stephen Amadei <amadei@dandy.net> writes:
> Hey guys... second post of the day.  If you read my last post about
> Postgres 7.2.1 segfaulting on Slackware 8.0, you noted I am trying to
> chroot Postgres.  Unfortunately, my chrooted postgres cannot create
> databases due to a 'system' call, which runs '/bin/sh'.

Ah.

> While, IMHO, the safest way to do this would be to code the cp and rm code
> internally, I have patched my copy to do a fork and execl to call the cp
> and rm programs directly (and placed /bin/cp and /bin/rm in the chroot
> jail) as a quick fix... I feel it gives a bit more security.

Why?  If you are launching daemon processes with insecure directories
in their $PATH, who are you gonna blame but yourself?

I don't really see an advantage to reinventing the cp and rm wheels
here...

            regards, tom lane

On Fri, 3 May 2002, Tom Lane wrote:

> > While, IMHO, the safest way to do this would be to code the cp and rm code
> > internally, I have patched my copy to do a fork and execl to call the cp
> > and rm programs directly (and placed /bin/cp and /bin/rm in the chroot
> > jail) as a quick fix... I feel it gives a bit more security.
>
> Why?  If you are launching daemon processes with insecure directories
> in their $PATH, who are you gonna blame but yourself?

Well, in my chroot jail, I have only a handful of files, most read only.
I'm just trying to make the most secure chroot jail as possible.
Obviously, running the daemon chrooted and as an unprivledged user goes a
long way, but I don't want to leave any chinks in my armor... especially
ones that may allow the exploiter to climb out of the chroot.

While I have full confidence in Postgres' security, sometimes underlying
libraries can have holes and can be exploited.  In the exploits I've seen,
they usually try to get a remote shell going... however this can't happen
in the chroot jail if /bin/sh isn't there.

> I don't really see an advantage to reinventing the cp and rm wheels
> here...

Well, reinventing the cp and rm commands isn't necessarily needed.  If
replacing the system call with a fork/execl call can help me avoid putting
/bin/sh in my chroot, great.  I would rather not put /bin/rm and /bin/cp
in my chroot, but they are not nearly as powerful a tool to try to break
out of the chroot as /bin/sh, so I can compromise.  ;-)

However, if someone was to know that Postgres needs a /bin/rm, an exploit
could be created that runs /bin/rm instead of /bin/sh and trashes the
databases postgres owns.  Of course, this is a big IF.  ;-)

I bring this idea up mostly because I think others may wish to put
Postgres in a chrooted environment, and this small coding change will
help them.  I also wondered if any odd side effects would occur...

                    ----Steve
Stephen Amadei
Dandy.NET!  CTO
Atlantic City, NJ

Stephen Amadei <amadei@dandy.net> writes:
> However, if someone was to know that Postgres needs a /bin/rm, an exploit
> could be created that runs /bin/rm instead of /bin/sh and trashes the
> databases postgres owns.  Of course, this is a big IF.  ;-)

The attacker won't be able to do any of this unless he's already managed
to connect to the database, no?  There are much easier ways to zap your
data at the SQL level.  Sorry but I'm having a hard time getting excited
about this proposition...

            regards, tom lane

On Sat, 4 May 2002, Tom Lane wrote:

> Stephen Amadei <amadei@dandy.net> writes:
> > However, if someone was to know that Postgres needs a /bin/rm, an exploit
> > could be created that runs /bin/rm instead of /bin/sh and trashes the
> > databases postgres owns.  Of course, this is a big IF.  ;-)
>
> The attacker won't be able to do any of this unless he's already managed
> to connect to the database, no?

Besides dbcommands.c, I have not looked over any Postgres code, so I
cannot be certain of what happens between socket connection and
authentication.  I'm just paranoid.  ;-)

> There are much easier ways to zap your
> data at the SQL level.

This assumes the user authenticated.  If the user authenticates, I
couldn't care less if they trash their own database via SQL.

> Sorry but I'm having a hard time getting excited
> about this proposition...

I don't blame you... it looks hard to do.  Maybe I'll try it later if I
get the time... for now I'm trying to wring out the last bugs of the
fork/execl change.

                    ----Steve
Stephen Amadei
Dandy.NET!  CTO
Atlantic City, NJ