Security jail sysvmsg, sysvsem, sysvshm do we really need all of them ?

[bryn1u]

Hi guys,

Im reading about sysvipc(depreceated) method in FreeBSD and wondering if all of them are necessary. I found some news on blog where were mentioned that shared memory isn't so secure and it's better to use only semaphores. But if we know that postgresql need access to sysvshm or not ?. Someone can explain to me a little bit more about those options ?

Also read that "new" options allow create own namespace in jail instead inherit from host.
Allowing sysvipc "... defeat the whole purpose of having a jail; privileged users from the jail would be able to affect processes outside the jailed environment."

Do you always guys use those 3 options: sysvmsg, sysvsem, sysvshm if yes, what really do you need them for ?
How to check which programs need those options ?

Thanks

Ehh. I don't why part of my post is crossed out ???

 

[Alain De Vos]

I would like to add a question.
What is the list of ports which still require sys V IPC ?
What is the list of ports which still use sys V IPC ?

 

[Alain De Vos]

PS, I found 3 things which might use sys V IPC :
1)aio
2)local_unbound
3)nfsd

 

[PMc]

18.4. Managing Kernel Resources

18.4. Managing Kernel Resources 18.4.1. Shared Memory and Semaphores 18.4.2. systemd RemoveIPC 18.4.3. Resource Limits 18.4.4. Linux Memory Overcommit 18.4.5. Linux …

www.postgresql.org

PostgreSQL requires the operating system to provide inter-process communication (IPC) features, specifically shared memory and semaphores. Unix-derived systems typically provide “System V” IPC, “POSIX” IPC, or both. Windows has its own implementation of these features and is not discussed here.

The complete lack of these facilities is usually manifested by an “Illegal system call” error upon server start. In that case there is no alternative but to reconfigure your kernel. PostgreSQL won't work without them. This situation is rare, however, among modern operating systems.

By default, PostgreSQL allocates a very small amount of System V shared memory, as well as a much larger amount of anonymous mmap shared memory. Alternatively, a single large System V shared memory region can be used (see shared_memory_type). In addition a significant number of semaphores, which can be either System V or POSIX style, are created at server startup. Currently, POSIX semaphores are used on Linux and FreeBSD systems while other platforms use System V semaphores.

 

[Alain De Vos]

So if you run postgresql in a jail you might need ?
security.jail.sysvipc_allowed=1

 

[20-100-2fe]

For PostgreSQL to work, you need to add the following lines to jail.conf:

sysvshm = new;
sysvsem = new;
sysvmsg = new;

 

[PMc]

So if you run postgresql in a jail you might need,
security.jail.sysvipc_allowed=1

It does not seem so:

$ sysctl security.jail.sysvipc_allowed
security.jail.sysvipc_allowed: 0

There is a more interesting section in the Postgres docs:

If running in FreeBSD jails by enabling sysctl's security.jail.sysvipc_allowed, postmasters running in different jails should be run by different operating system users. This improves security because it prevents non-root users from interfering with shared memory or semaphores in different jails, and it allows the PostgreSQL IPC cleanup code to function properly. (In FreeBSD 6.0 and later the IPC cleanup code does not properly detect processes in other jails, preventing the running of postmasters on the same port in different jails.)

But then, in the jail(8), it reads:

             allow.sysvipc
                     A process within the jail has access to System V IPC
                     primitives.  This is deprecated in favor of the per-
                     module parameters (see below).  When this parameter is
                     set, it is equivalent to setting sysvmsg, sysvsem, and
                     sysvshm all to “inherit”.
[...]
     sysvmsg
             Allow access to SYSV IPC message primitives.  If set to
             “inherit”, all IPC objects on the system are visible to this
             jail, whether they were created by the jail itself, the base
             system, or other jails.  If set to “new”, the jail will have its
             own key namespace, and can only see the objects that it has
             created; the system (or parent jail) has access to the jail's
             objects, but not to its keys.  If set to “disable”, the jail
             cannot perform any sysvmsg-related system calls.

     sysvsem, sysvshm
             Allow access to SYSV IPC semaphore and shared memory primitives,
             in the same manner as sysvmsg.

So, it is enough to set only sysvshm per respective jail. And it sounds like this should be (more or less) safe.

 

[bryn1u]

So if you run postgresql in a jail you might need,
security.jail.sysvipc_allowed=1

security.jail.sysvipc_allowed=1 - When this parameter is set, it is equivalent to setting sysvmsg, sysvsem, and sysvshm all to "inherit". Allowing sysvipc "defeat the whole purpose of having a jail privilege users from the jail would be able to affect proccesses outside the jailed environment". That's why you should never use "sysvipc_allowed"

Instead of "security.jail.sysvipc_allowed" you should use in jail.conf parameters with "new" options.:

sysvmsg = new;
sysvsem = new;
sysvshm = new;

If set to "new", the jail will have its own key namespace, and can only see the objects that it has created; the system (or parent jail) has access to the jail's objects, but not to its keys.

Postgresql needs only sysvshm = new
With the new method, it suffices to set sysvshm = "new"; for the jails in question. In this case, each jail can only see its own information:

pgsql01 / # ipcs
Message Queues:
T           ID          KEY MODE        OWNER    GROUP

Shared Memory:
T           ID          KEY MODE        OWNER    GROUP
m       131072      5432001 --rw------- postgres postgres

Semaphores:
T           ID          KEY MODE        OWNER    GROUP

pgsql02 / # ipcs
Message Queues:
T           ID          KEY MODE        OWNER    GROUP

Shared Memory:
T           ID          KEY MODE        OWNER    GROUP
m       655361      5432001 --rw------- postgres postgres

Semaphores:
T           ID          KEY MODE        OWNER    GROUP

Interestingly, the host on which the jails are running would still be able to see both “namespaces”:

~ # ipcs
Message Queues:
T           ID          KEY MODE        OWNER    GROUP

Shared Memory:
T           ID          KEY MODE        OWNER    GROUP
m       131072            0 --rw------- 770      770
m       655361            0 --rw------- 770      770

Semaphores:
T           ID          KEY MODE        OWNER    GROUP