GSoC 2017 Final Proposal - LogVM

[Alisa Matsak]

Hi all!

Here is the final version of my proposal in Google Docs.

Please, let me know if anything else should be corrected and I'll try to fix it before the deadline.

Thank you very much!

Regards,
Alisa.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Apr 03, 2017 at 06:00:35AM -0700, Alisa Matsak wrote:
> Hi all!
>
> Here
> <https://docs.google.com/document/d/18Ob3jwnCgV05BqdSKcF-WH097AeATBV1uT9AFXEr5hg/edit?usp=sharing>

> is the final version of my proposal in Google Docs.
>
> Please, let me know if anything else should be corrected and I'll try to
> fix it before the deadline.

I've reviewed it briefly and it mostly looks fine. Not sure about the
timeline - IMO you've underestimated time for the GUI part, but on the
other hand, you also noted where you expect to save some time to
reallocate it to GUI. So, it may be also this way.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJY4kwRAAoJENuP0xzK19csfQwH/iw/OQOXkmOz915uXeCQxmq4
x+eyAWVLwa5/citsxfkpn+SD+lx8+IP9DPuwSiLpnf94dx2KRW/kKKGTSsqBb3Zr
bOYwz8FqQ+rkXLxha2UhQufQCwOkWYd7+ZrjPA+Zny7k2NGXLbCwCpFPP3j68/M6
L+0IK2UQkedH+L+yOxgLK9biPNWmiAlgS3m4m+BOgPp84wi+Nxlhh1FBP9wO4Xn1
Z8zKMN21sgP0EpTmM0r30dk9GfEWXUeDCe+HNimuxSkEZDIQDhEKK0pIcv9qzOvf
E/yb9RS89YupfcwTj760Gn7UPtCeyI5dJz0O+hmvueYcMZ0UyArXnfE3io3va9M=
=ArRJ
-----END PGP SIGNATURE-----

[Tray Torrance]

Just wanted to note that it may be worth evaluating Logstash as a potential collector in the LogVM.

While the code base is large, the project itself is modular, so by limiting how many plugins are utilized/custom written, the attack surface may be acceptable.

Note that it addresses a number of the goals of the log collector specified here.

I have a good deal of experience in both, contributing and administering the stack, so I'm happy to provide some guidance in that area if it is useful/desired.

--
You received this message because you are subscribed to the Google Groups "qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20170403132015.GI15825%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

[Alisa Matsak]

On Monday, 3 April 2017 16:20:23 UTC+3, Marek Marczykowski-Górecki wrote:

I've reviewed it briefly and it mostly looks fine. Not sure about the
timeline - IMO you've underestimated time for the GUI part, but on the
other hand, you also noted where you expect to save some time to
reallocate it to GUI. So, it may be also this way.

Thank you for your feedback!

[Alisa Matsak]

On Monday, 3 April 2017 21:48:12 UTC+3, Warren Torrance wrote:

Just wanted to note that it may be worth evaluating Logstash as a potential collector in the LogVM.

While the code base is large, the project itself is modular, so by limiting how many plugins are utilized/custom written, the attack surface may be acceptable.

Note that it addresses a number of the goals of the log collector specified here.

I have a good deal of experience in both, contributing and administering the stack, so I'm happy to provide some guidance in that area if it is useful/desired.

Well, that is an interesting point. Jean-Philippe also warned me that we should be careful to avoid reinventing the wheel in the LogVM side. So, Logstash can be a possible decision too.

In any case, it's really kind of you to offer assistance in this matter. I will definitely learn more about Logstash and come back to ask you questions. ;)

[Chris Laprise]

Hi Alisa,

I read the proposal and a question occurred to me: Would it be possible
to also make "LogVM" an assigned property in dom0, much as "ClockVM" and
"UpdateVM" are? This would allow the user to choose which VM performs
the logging.

It also touches on a possible third aspect to implementing a LogVM, a
dom0 management side.

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Jean-Philippe Ouellet]

On Tue, Apr 4, 2017 at 6:00 PM, Chris Laprise <tas...@openmailbox.org> wrote:
> I read the proposal and a question occurred to me: Would it be possible to
> also make "LogVM" an assigned property in dom0, much as "ClockVM" and
> "UpdateVM" are? This would allow the user to choose which VM performs the
> logging.
>
> It also touches on a possible third aspect to implementing a LogVM, a dom0
> management side.

A good question, but I think not the desired approach.

I was imagining the VMs would send the logs via qrexec service, which
makes it quite easy to specify destination in dom0 config:

in /etc/qubes-rpc/qubes.SendLogs (or so) have:
$anyvm $anyvm allow,target=my-logvm

This has the added benefit of being able to specify destination logvm
on a per-sender basis, e.g.
build-fedora $anyvm allow,target=build-logs
build-debian $anyvm allow,target=build-logs
$anyvm $anyvm allow,target=default-logvm

Note also that 2nd $anyvm parameter (destination) will become optional
/ disappear in the long-term future. [1]

[1]: https://github.com/QubesOS/qubes-issues/issues/910