Skip site navigation (1) Skip section navigation (2)

Re: Why does Postgres need the /bin/sh?

From: Stephen Amadei <amadei(at)dandy(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Why does Postgres need the /bin/sh?
Date: 2002-05-04 04:32:11
Message-ID: Pine.LNX.4.44.0205040015180.1906-100000@rastaban.dandy.net (view raw or flat)
Thread:
Lists: pgsql-bugs
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


In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2002-05-04 14:48:47
Subject: Re: 7.2.1 segfaults.
Previous:From: Stephen AmadeiDate: 2002-05-04 04:14:38
Subject: Re: 7.2.1 segfaults.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group