[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

msgcollector security hardening

No idea why x was included there.

Could you try please if it still works when removing permission x there?


Would also be good to have confinement for:


Alternatively whole msgcollector could be radically rewritten and simplified but looks like quite some work.


//cc @madaidan

1 Like

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.

1 Like

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.

1 Like

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.

1 Like

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?

1 Like

User someuser cannot show a (zenity) popup for user user. At least when I experimented with that.

If you like to experiment:

  • Try login as user someuser (yet to be created).
  • Yes, login. Virtual console or another X login session.
  • sudo -u someuser zenitycommand is invalid (maybe because still same .Xauthority file).
1 Like

Ahh. That can be fixed by running xhost +local:. Or, if you only want to allow a single user to connect to the display, xhost +SI:localuser:someuser.

https://github.com/Whonix/msgcollector is still weird.

whonixcheck runs under user whonixcheck for better hardening (linux user account separation). It’s auto started as a daemon:
https://github.com/Whonix/whonixcheck/blob/master/lib/systemd/system/whonixcheck.service

Usually daemons don’t send GUI notifications.

msgdispatcher (part of msgcollector package) is started by:

msgdispatcher runs as user user.

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.

Dunno how to sort this out better.

Leading to issue [msgdispatcher] bug: "$delete_wrapper"

Considering to deprecate whonixcheck. Feature reduction:

1 Like

Another issue was reported here: Running X on Workstation-CLI

When removing user user from group sudo then https://github.com/Whonix/msgcollector/blob/master/etc/sudoers.d/msgcollector will break.

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.

removing user user from group sudo is actually recommended here: https://www.whonix.org/wiki/Root#Prevent_Malware_from_Sniffing_the_Root_Password

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]