Template logs are their corresponding AppVMs

[emkll]

This will make debugging updates more difficult, and will make it difficult to distinguish.

Ideally, we would want to detect the VM based on the qrexec call. @kushaldas , is there a way we can detect the source of the ? Otherwise a compromised VM could spoof log source.

If we cannot detect source VM based on qrexec call, we should consider the following:
Replace vmname context in the configuration step to the that of the template [1] the and for AppVMs use the strategy used in sd-whonix via rc.local[2]

[1]

securedrop-workstation/dom0/sd-devices-files.sls

Line 36 in c54d5dd

sd-rsyslog-for-sd-devices:

[2]

securedrop-workstation/dom0/sd-whonix-rsyslog-enable.sls

Line 27 in c54d5dd

sd-rc-enable-logging:

[kushaldas]

We should follow the [2] like sd-whonix in all VMs.

[conorsch]

Another option is to use the hostname reported by the logclient machine, e.g. via hostname, rather than hardcoding the client name in a config file. Doing so would clearly distinguish between Template & AppVMs, as well as allow us to delete a considerable amount of configuration logic. Example of inferring hostname: https://github.com/freedomofpress/securedrop-log/compare/infer-hostname

The problem of "a compromised AppVM can claim to be a differently named VM" is a separate issue, and one I don't think we should try hard to solve for the pilot, where logging will be most useful for debugging application components. When we try to resolve the masquerade problem, we should consider using dom0 to aggregate and store the logs, since dom0 already stores all syslog for each VM, with unique names for Template & AppVMs. See related comment #463 (comment)