Linux: Can unprivileged users tamper with processes running under their own identity?

Question

Having the following pseudocode executed by a superuser, is it safe to assume that it is secure on Linux?

if fork() == 0:
   # drop privileges to an unprivileged user, let's say "nobody"
   # perform various tasks, start other processes as "nobody"
   # communicate with parent process through unsafe means, e.g. Python pickle

Now, Pickle is known to be susceptible to RCE if the data to be unpickled comes from an untrusted source. Although I assume my own code to be free of vulnerabilities, my concern is that the above code could still be vulnerable to privilege escalation through another process running as "nobody" that tampers with the memory of the unprivileged fork. If "nobody" could tamper with the memory of the process, it could potentially inject a pickled object which then leads to remote code execution in the parent process, i.e. as root user, which would be a privilege escalation. On the systems I tested this on, e.g. through writing to /proc/$pid/mem, I was able to tamper with the memory of another process only as superuser. However, I prefer to not just rely on a few tests on Linux machines where the behavior could depend on the distribution/configuration.

So my question is: Is this code secure? If so, where can I find a documentation guaranteeing that this behavior is universally secure? Alternatively, is there an argument that shows that a system would be inherently unsafe if it allowed an unprivileged user to tamper with all other processes running under their user id?

A question on how to implement secure child-to-parent communication in a setting where the child drops permissions has already been asked on Stackoverflow and since the accepted answer uses pickling under the hood, my question boils down to whether this approach is really secure.

Answer 1

If you start a process as yourself and you can't trust that other process, then yes, all your processes are vulnerable.

Root can generally access everything unless you have LinuxSE in which case root is not allowed to access other user's processes (at least by default), it can still see that they are running and send signals, though.

If you want to start another process in a more secure way, you have to

1. fork()
2. start a process that can change to that other user (i.e. suid bit set)
3. change to that other user
4. start the possibly non-secure process as that other user

systemd does a lot of that with services. Many services run as a user that's not root. In some cases, though, it starts as root (apache2) and change to another user later (www-data under Ubuntu) so the processes actually dealing with client connections are not running as root. But root is required to open port 80 and 443 (below 1024).

Actually systemd also has an option that defines how many child processes your service can start. It can be set to 0 in which case a simple system() call will fail every time (very strange when you don't know that the OS is capable of controlling that!) So there is definitely a potential security issue in starting any other process you're not 100% in control of. At the same time, this is very much the Unix way.

Another solution is to run everything in a docker so at least the main server can't be attacked directly. Your docker may get hacked, but you can always re-install and restart quickly (and work on a fix to prevent the hack from happening again, after you blocked that IP address in iptables).