Thread: 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