Scott Marlowe wrote:
On Thu, 2005-05-19 at 09:46, lister wrote:
At the BSDCan tutorial last week on jails (and several other times)
there was discussion regarding Postgres's use of system V style
shared memory, and an unfortunate side effect of making jail() less
secure. Specifically, to allow Postgres to operate in a jail()ed
environment, the sysctl :
jail.sysvipc_allowed=1
has to be set. This allows ALL jails to access the memory, at the least
leaving Postgres open to attack, at the worst allowing a door into who
knows what security breach.
Question : is there any way to run Postgres securely in a jail?
I'm note sure that this is an actual security issue. Assuming that the
processes running each jail are running under a different UID, they
shouldn't be anymore able to access each other's shared memory than they
would be able to share each others files.
In a strict definition of 'issue' you may be right (I am not a security officer) but speaing from a practically perspective : 1) One of the purposes of jail is to contain a breach, making a compromised server a matter of restoring a directory, not a system rebuild. A break-in is often not the result of one software fault, but a set of steps. If one jail is rooted, the postgres jail can be abused. 2) Many hosting companies use jail() to deliver a pseudo machine to customers, with root privs. This effectively bars postgres from this senerio. This was the topic of 20 minutes of conversation in 2 tutorials at BSDCan.
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@xxxxxxxxxxxxxx
