logvm(s) #830

Open
marmarek opened this Issue Mar 8, 2015 · 7 comments

Projects

None yet

3 participants

@marmarek
Member
marmarek commented Mar 8, 2015

Reported by joanna on 25 Apr 2014 16:41 UTC
A VM to collect logs from other VMs via qrexec service. Allow tools to easy copy logs to other VMs, as well as do log processing (logs are untrusted, but the logvm should be considered not-sensitive).

Potentially allow more than one logvm for paranoid configurations, cofigurable via qrexec policy.

Migrated-From: https://wiki.qubes-os.org/ticket/830

@marmarek marmarek added this to the Release 3 milestone Mar 8, 2015
@marmarek marmarek modified the milestone: Release 3.1, Release 3.0 May 13, 2015
@marmarek marmarek modified the milestone: Release 4.1, Release 3.1 Jan 4, 2016
@Rudd-O
Rudd-O commented May 11, 2016

This is EXCELLENT.

Plus, with journald log replication, it should be trivial to do.

Care must be taken that the files received by the logvm do not compromise the logvm upon using journalctl to read those logs.

@andrewdavidwong
Member

@Rudd-O: Would you be interested in taking this on?

@andrewdavidwong andrewdavidwong added a commit that referenced this issue Jun 9, 2016
@andrewdavidwong andrewdavidwong Update #830 status e0879c6
@Rudd-O
Rudd-O commented Jun 12, 2016

I wish I could, but I am extremely busy.

Is this intended to send/receive arbitrary logs, or specific structured logs like systemd ones? systemd has a good protocol for incremental send and receive of logs, and it is quite possible that it can be adapted to this use case with a minimal shim.

What's the idea w.r.t. who initiates the copy? Is it the logvm that extracts logs from other machines? Or is it the VM producing the log entries which sends it to the logvm?

@marmarek
Member

Is this intended to send/receive arbitrary logs, or specific structured logs like systemd ones? systemd has a good protocol for incremental send and receive of logs, and it is quite possible that it can be adapted to this use case with a minimal shim.

I think it's fair assumption to have systemd (or generally syslog-like) logs. But this shouldn't use any complex protocol, to not expose too much code for attacks. It looks like a simple "one log message per line" should be enough.

What's the idea w.r.t. who initiates the copy? Is it the logvm that extracts logs from other machines? Or is it the VM producing the log entries which sends it to the logvm?

Logically VM producing the logs should send them to logvm. After all it know when there is anything for sending, so no need for polling. Maybe even send logs to logvm instead of writing them to /var/log (or /var/log/journal).

@Rudd-O
Rudd-O commented Jun 12, 2016

On 06/12/2016 06:09 PM, Marek Marczykowski-Górecki wrote:

Is this intended to send/receive arbitrary logs, or specific
structured logs like systemd ones? systemd has a good protocol for
incremental send and receive of logs, and it is quite possible
that it can be adapted to this use case with a minimal shim.

I think it's fair assumption to have systemd (or generally
syslog-like) logs. But this shouldn't use any complex protocol, to not
expose too much code for attacks. It looks like a simple "one log
message per line" should be enough.

You would lose a LOT of useful and certified metadata if you only
ingested "one message per line" syslog-style logs. Perhaps the format
used by systemd-journald log forwarding is not suitable for what you
want to do, or perhaps it is.

Look into how it works.

What's the idea w.r.t. who initiates the copy? Is it the logvm
that extracts logs from other machines? Or is it the VM producing
the log entries which sends it to the logvm?

Logically VM producing the logs should send them to logvm. After all
it know when there is anything for sending, so no need for polling.
Maybe even send logs to logvm /instead of/ writing them to |/var/log|
(or |/var/log/journal|).

Send instead of write sounds like a sensible thing.

It sounds like what you want is a systemd-journald log forwarder on each
client VM, continually sending log data over a vchan connection to the
log VM. That should not be very difficult to do.

Rudd-O
http://rudd-o.com/
@marmarek
Member

It sounds like what you want is a systemd-journald log forwarder on each client VM, continually sending log data over a vchan connection to the log VM.

Yes, something like this. But the priority is to not allow such logvm being compromised with some mis-formatted message. If that requirement means dropping some metadata, so be it.

@Rudd-O
Rudd-O commented Jun 12, 2016

On 06/12/2016 06:31 PM, Marek Marczykowski-Górecki wrote:

It sounds like what you want is a systemd-journald log forwarder
on each client VM, continually sending log data over a vchan
connection to the log VM.

Yes, something like this. But the priority is to not allow such logvm
being compromised with some mis-formatted message. If that requirement
means dropping some metadata, so be it.

This is why the receiving code in the systemd log forwarder needs to be
reviewed. I expect it to be generally better than other stuff, if only
because it is meant to be exposed as a service on a network. If, for
some reason, the code does not meet your security standards, then the
two sides of the vchan connection can do serialization and deserialization.

If you reuse the log forwarder system, you also get forward secure
sealing of logs from VMs. That means a VM cannot tamper with old log
entries (without it becoming evident) no matter what it tries to do.

Rudd-O
http://rudd-o.com/
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment