Simplification: reconsider necessity of sd-log

[deeplow]

Description

With @zenmonkeykstop we came to the conclusion that sd-log may not need to exist, especially given what it currently provides.

Properties of sd-log:

• append-only
• realtime - Logs are saved rigth away with no ability for sudden VM shutdowns to corrupt part of a log
• offline VM
• are there any other properties that I am missing? (I took a look through README.md and the original issue)
• not needing to tell people to share logs by doing things in dom0

What would replace it?

• System logs are already available in dom0. So technically we don't need to log collection server. We still need to setup logging in applications such that it goes to syslog, but the rest feels a bit duplicated.

• We could later even add a little utility to view the logs like what qubes manager does. Something extremely simple:

  

Is there something that we're missing here? If the above assumptions / properties are correct all that we'd need to ensure is that the logs in dom0 are append-only.

How will this impact SecureDrop/SecureDrop Workstation users?

It should not.

How would this affect the SecureDrop Workstation threat model?

It should not.

[deeplow]

I should also add that I do see a few scenarios where sd-log would be useful:

• for log parsing / analysis (in dom0 we don't want to do any parsing)
• if there is a management qube and we have a simple log viewer application (dom0 would no longer be an "acceptable" place to add multiVM-specific applications)

However, this is not the case as of today and is not in the roadmap.

[zenmonkeykstop]

There is one downside that came to me after - as sd-* are app or dispvms, some system logs might get wiped with shutdown. application logs would persist for sd-app and -proxy though.

[deeplow]

Good point. I added that to the list of "current properties of sd-log":

realtime - Logs are saved rigth away with no ability for sudden VM shutdowns to corrupt part of a log

[lsd-cat]

I'm a bit outside in the Qubes loop, I'd be curious to know what kind of involvement of system services is in the communication and parsing now, versus how much would be if we removed the logging Qube.

My question is to understand the attack surface now in dom0 versus the attack surface later. So now we pass through the qrexec or whatever communication daemon, and then it gets consumed by sd-log. But if we, change the target app, wouldn't this bring as dom0 attack surface the dom0 rsyslogd?

[deeplow]

My question is to understand the attack surface now in dom0 versus the attack surface later. So now we pass through the qrexec or whatever communication daemon, and then it gets consumed by sd-log. But if we, change the target app, wouldn't this bring as dom0 attack surface the dom0 rsyslogd?

Thanks for chiming in. In reality we're not adding any more attack surface than what's already there. The system logs from the various Qubes are already available in dom0. It's not exactly the same data, but we can make it be the same.

The dom0 logs are basically the console output of the VMs (dmesg basically), whereas sd-rsyslog I guess is the output of journalctl. But we could easily get the systemd log in dom0 this way as well by running in all sd-related qubes journalctl -f | sudo tee /dev/hvc0. Yes, it feels a bit hacky, but it's nothing that a compromised VM couldn't already "send to dom0".

If you're curious, you can check out what the logs look like by downloading from OpenQA (here, for example) the file collect_logs-var_log.tar.gz, extracting it and then going to /var/log/xen/console and opening the .log for the VM you're looking for.

So as long as we don't do any additional parsing, the attack surface should be pretty much the same. If anything, it decreases because there is one less VM in the game, as in "one less VM to hack" (e.g. if there is an issue with the securedrop.Log RPC server / client, thus allowing for "VM escapes" (without breaking Qubes / Xen itself).

[legoktm]

I want to cross-link #529 here, since I think that's one of the biggest unaddressed use cases. To @lsd-cat's point, I'm less concerned about logs ending up in dom0 and am more worried about asking journalists/admins to do stuff in dom0 (compared to a VM).

[deeplow]

Fair point. I think a simple user log-viewer interface with a simple button to share logs (#529) could be a pragmatic way to avoid telling people to do things in dom0. Technically it's still dom0, but a much more narrow-focused / less complex task.