Re: Shared memory and FreeBSD's jail()

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?

lister <lister(at)primetime(dot)com> writes:

> 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?

By your definition, not unless you remove the dependence on SysV
shmem, which would be a lot of work.

-Doug

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.

lister <lister(at)primetime(dot)com> writes:
> 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.

This claim is really pretty bogus, since there is still standard
file-permission-like security on the shared memory. Only if you give
usage of the postgres account to processes running in other jails is
there any risk.

regards, tom lane

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.

On Thu, 2005-05-19 at 10:49, lister wrote:
> 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.

Ahh, ok. Seems to me the bug here is that jails can't provide localized
shared memory implementations. If jails provided local virtual shared
memory, there would be no problem.

But the real solution to me is to move right on to actual server
virtualization. There are quite a number of open source virtualization
projects out there, and once they reach maturity, I would use them. Til
then, someone might want to fix the jail implementation to enclose the
shared memory it uses in something similar to the rest of the jail.

lister <lister(at)primetime(dot)com> writes:
> This was the topic of 20 minutes of conversation in 2 tutorials
> at BSDCan.

Well, if the BSD people are so concerned about it, why don't they fix
their bleedin' OS? It's inexcusable to have a "jail" feature that
doesn't cover such a major part of Unix as the SysV IPC facilities.

Of course, it's a lot easier to just blame the messenger.

regards, tom lane

# tgl(at)sss(dot)pgh(dot)pa(dot)us / 2005-05-19 12:14:58 -0400:
> lister <lister(at)primetime(dot)com> writes:
> > This was the topic of 20 minutes of conversation in 2 tutorials
> > at BSDCan.
>
> Well, if the BSD people are so concerned about it, why don't they fix
> their bleedin' OS? It's inexcusable to have a "jail" feature that
> doesn't cover such a major part of Unix as the SysV IPC facilities.
>
> Of course, it's a lot easier to just blame the messenger.

I read current@, hackers@, stable@, and ports@, and none of
the threads revolving around jails, SysV shared memory and
PostgreSQL I read blamed PostgreSQL of anything.

Closest it got was when Dag-Erling Smorgrav (the spelling is not
correct, sorry DES) mentioned that making PostgreSQL use POSIX-style
shm would eliminate the problem (I have no idea if that's true).

--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991