msgcollector is started by whonixcheck so the systemd sandboxing for whonixcheck should also be applied to msgcollector (only if started with whonixcheck.service).
I don’t know enough about msgcollector to create any confinement for it but it seems apparmor would be good to use for this.
The more I think about it it should be rewritten / radically simplified. The feature “notify CLI users who don’t start whonixcheck” abolished for the gain in simplicity and security.
hidepid=2 breaks msgcollector since it needs to check msgdispatcher if/already running. whonixcheck runs under user whonixcheck while msgdispatcher needs to run under user user to be able to show GUI messages. Adding a sudoers exception might be hard to get right without leaving a hole for running ps -p arbitrary.
We can get rid of msgdispatcher by mostly deprecating GUI support of whonixcheck and tb-updater. These do not seem that much important anymore nowadays.
On the graphical desktop when started from start menu: whonixcheck / tb-updater console version on manual run could be run inside a terminal emulator.
We could create the proc group, mount /proc with gid=proc, make msgdispatcher run as a different user and add that user to the proc group. This way, msgdispatcher won’t be effected by hidepid=2 and we won’t need to mess with a sudoers exception.
Why does it need to be run under that user? Can’t any user show GUI messages?
Ultimately for better hardening we wouldn’t want user user have access to information by whonixcheck (can include logs) without use of sudo.
When whonixcheck runs it uses msgcollector which then creates files in /run/msgcollector/whonixcheck folder which msgdispatcher reads (inotifywait), processes (shows) and the deletes. In this weird setup user user (msgdispatcher) needs permission to delete files created by user whonixcheck.
We could hardcode user user additionally in /etc/sudoers.d/msgcollector but it’s still a bad solution. I don’t see how msgcollector could compatible with multi user and without sudo exceptions.