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.