Ambient Capabilities

[stevegrubb]

I was scanning my system and found that earlyoom has ambient capabilities. I grepped the symbol table and can't find any execve, popen, or system function calls. Why does it need ambient capabilities?

[hakavlad]

                res = kill(pid, sig);

https://github.com/rfjakob/earlyoom/blob/master/kill.c#L93

        err = mlockall(MCL_CURRENT | MCL_FUTURE);

https://github.com/rfjakob/earlyoom/blob/master/main.c#L315

       CAP_KILL
              Bypass permission checks for sending signals (see kill(2)).
              This includes use of the ioctl(2) KDSIGACCEPT operation.

       CAP_IPC_LOCK
              Lock memory (mlock(2), mlockall(2), mmap(2), shmctl(2)).

https://man7.org/linux/man-pages/man7/capabilities.7.html

[stevegrubb]

My concern is not what capabilities the program needs. Its why ambient? The ambient capabilities are for inheritance to child processes. If you spawn helper processes that need CAP_KILL and CAP_IPC_LOCK, fine. I am not seeing where they are spawned. If you need capabilities for immediate use, then you would ask for effective and permitted capabilities, but not inheritable or ambient. The issue is if an attacker can exploit the program, then any shell they can pop will have the capabilities.

[hakavlad]

Ambient capability sets are useful if you want to execute a process as a non-privileged user but still want to give it some capabilities.

https://www.freedesktop.org/software/systemd/man/systemd.exec.html#AmbientCapabilities=

The ambient capabilities are for inheritance to child processes.

Actualy ambient capabilities may by used by parent process. Using ambient capabilities was recommended by Lennart for earlyoom:

BTW, this should not be a root daemon anyway. It only needs one cap:
CAP_SYS_KILL. Hence, drop privs to some user of its own, and keep that
one cap. Use AmbientCapabilities= in the unit file.

https://lists.fedoraproject.org/archives/list/[email protected]/message/YBX4TTRXHKB3ZHXFGWFRNBONHZPWM3IJ/

[stevegrubb]

OK, I dug into his recommendation. What is happening is that a privileged parent can select capabilities and they are passed on at fork. However, if your uid is not 0, then all capabilities are reset during execve. So, the only way to offer capabilities to scripts and things that do not want to deal with capabilities is by using ambient capabilities. This allows them to be passed on. Unfortunately, they can be passed on infinitely. But, there is a simple fix. I spent some time running some experiments today to see what's the best solution. I think that just doing this:

prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_CLEAR_ALL, 0, 0, 0);

fixes the issue of leaky capabilities. You would do that in main first thing in case there is any issue with command line options. I am writing up my experiments for a blog so that other's can understand the evolution of ambient capabilities under various attempts to stop the spread. With the prctl solution, you do not need to link to any extra libraries and that makes it simplest.

[rfjakob]

Would you like to create a pull request for this? It looks very good.

[stevegrubb]

OK, opened pull request #228.

[stevegrubb]

Patch was merged, Thanks! Closing.