On a Linux system if you upgrade a shared object that is in use any programs that have it mapped will list it as “(deleted)” in the /proc/PID/maps file for the process in question. When you have a system tracking the stable branch of a distribution it’s expected that most times a shared object is upgraded it will be due to a security issue. When that happens the reasonable options are to either restart all programs that use the shared object or to compare the attack surface of such programs to the nature of the security issue. In most cases restarting all programs that use the shared object is by far the easiest and least inconvenient option.
Generally shared objects are used a lot in a typical Linux system, this can be good for performance (more cache efficiency and less RAM use) and is also good for security as buggy code can be replaced for the entire system by replacing a single shared object. Sometimes it’s obvious which processes will be using a shared object (EG your web server using a PHP shared object) but other times many processes that you don’t expect will use it.
I recently wrote “deleted-mapped.monitor” for my etbemon project [1]. This checks for shared objects that are mapped and deleted and gives separate warning messages for root and non-root processes. If you have the unattended-upgrades package installed then your system can install security updates without your interaction and then the monitoring system will inform you if things need to be restarted.
The Debian package debian-goodies has a program checkrestart that will tell you what commands to use to restart daemons that have deleted shared objects mapped.
Now to solve the problem of security updates on a Debian system you can use unattended-upgrades to apply updates, deleted-mapped.monitor in etbemon to inform you that programs need to be restarted, and checkrestart to tell you the commands you need to run to restart the daemons in question.
If anyone writes a blog post about how to do this on a non-Debian system please put the URL in a comment.
While writing the deleted-mapped.monitor I learned about the following common uses of deleted mapped files:
- /memfd: is for memfd https://dvdhrm.wordpress.com/tag/memfd/ [2]
- /[aio] is for asynchronous IO I guess, haven’t found good docs on it yet.
- /home is used for a lot of harmless mapping and deleting.
- /run/user is used for systemd dconf stuff.
- /dev/zero is different for each map and thus looks deleted.
- /tmp/ is used by Python (and probably other programs) creates temporary files there for mapping.
- /var/lib is used for lots of temporary files.
- /i915 is used by some X apps on systems with Intel video, I don’t know why.
The combination of needrestart and needrestart-session are a better option for this:
https://github.com/liske/needrestart
https://github.com/liske/needrestart-session
Could you specifically check for deleted executable mappings? That would distinguish code from data files.
What is “systemd dconf stuff”? Systemd does not use dconf and dconf does not really use systemd.
Paul: Thanks, I’ll look into that.
Josh: You can check for executable mappings. But that’s not always useful. For example if a config file in /etc is mapped and deleted then it could be a security issue that the new version of the file is not applied to the running state, of course this could also happen with a file that was read and closed. I’m not convinced that executable mappings is the only useful check for such things.
Jan: /usr/lib/at-spi2-core/at-spi-bus-launcher has /run/user/1000/dconf/user mapped. I took everything under /run/user to be related to systemd, seems it’s really $XDG_RUNTIME_DIR/dconf/user .