Apply some basic privilege seperation

[leonlag]

Currently murmur runs a single process for all task and does not attempt to do any sandboxing or privilege separation. This means that an attacker that manages to find a flaw in murmur can access the whole application.

We should start by splitting murmur into logical process groups. A root process(running as root) should delegate tasks to less privileged, sub processes. I can imagine splitting processes like this:

• root that spawns other processes
• connection handler
• database reader/writer
• TLS process(one per virtual server)
• main process(one per virtual server)

Note: This is just an example and the actual tasks will probably look different.

These processes can then run under their own users, have their own seccomp filters/SELinux Policies, run in a separate namespace or use other operating system specific privilege separation mechanisms(openbsd pledge/unveil for example).

Obviously this is a huge undertaking and is probably impossible to just tack onto the current implementation. However, I have not seen anything like this discussed on the bugtracker and since there are talks of a rewrite I thought I should mention it.

[Krzmbrzl]

That definitely sounds reasonable. And you are correct that this probably won't work by adapting the current implementation but it might be worth to keep in mind when starting to refactor the code :point_up:

[mk-pmb]

On systems where systemd is available, we can probably mitigate attacks further by running as a low-privilege user. Murmurd can receive its listening sockets and SSL keys via file descriptors.

[savchenko]

On systems where systemd is available

[Service]
RestrictNamespaces=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
# ...

?