Re: Shared memory and FreeBSD's jail()
От | lister |
---|---|
Тема | Re: Shared memory and FreeBSD's jail() |
Дата | |
Msg-id | 428CB588.5040906@primetime.com обсуждение исходный текст |
Ответ на | Re: Shared memory and FreeBSD's jail() (Scott Marlowe <smarlowe@g2switchworks.com>) |
Ответы |
Re: Shared memory and FreeBSD's jail()
Re: Shared memory and FreeBSD's jail() |
Список | pgsql-general |
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.
В списке pgsql-general по дате отправления: