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


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to