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