msgcollector security hardening

Patrick · June 27, 2019, 4:31pm

Whonix/msgcollector/blob/master/usr/lib/msgcollector/msgdispatcher_init

#!/bin/bash

## Copyright (C) 2012 - 2020 ENCRYPTED SUPPORT LP <adrelanos@riseup.net>
## See the file COPYING for copying conditions.

set -e

umask ug=rw,o=r || exit 2

DONE_FILE="/run/msgcollector/init_done"
SIZE="10M"

mkdir --parents /run/msgcollector || exit 3

if [ ! -f "$DONE_FILE" ]; then
    mount -t tmpfs -o size="$SIZE",nosuid,nodev,noexec none /run/msgcollector || exit 4
else
    mount -t tmpfs -o size="$SIZE",nosuid,nodev,noexec,remount none /run/msgcollector || exit 5
fi

This file has been truncated. show original

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

madaidan · June 27, 2019, 4:37pm

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.

Patrick · June 27, 2019, 4:40pm

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.

Patrick · July 1, 2019, 3:22pm

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.

madaidan · July 1, 2019, 3:27pm

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?

Patrick · July 1, 2019, 3:35pm

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

madaidan · July 1, 2019, 3:41pm

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.

Patrick · July 6, 2019, 1:48pm

Patrick · September 9, 2019, 9:57am

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:

no more automated (not asked for) notifications for CLI users in tty1 (as per https://www.whonix.org/wiki/Desktop#Whonixcheck_Writing_to_tty1)
no more whonixcheck GUI popup
whonixcheck would be a CLI only tool but thereby a lot simpler message notification system

Patrick · September 9, 2019, 10:13am

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