[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.