Need VM GUI when startup service fails

70 views
Skip to first unread message

Chris Laprise

unread,
Jun 6, 2017, 6:43:05 PM6/6/17
to qubes...@googlegroups.com
Per
https://github.com/tasket/Qubes-VM-hardening/issues/7#issuecomment-306637475

If a Qubes startup service (in this case, qubes-mount-dirs) fails, there
is no GUI after startup, even though the other services seem to have
started OK.

I am looking for a way to have the VM notify the user when one of its
startup services fail.

--

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

Marek Marczykowski-Górecki

unread,
Jun 6, 2017, 7:20:56 PM6/6/17
to Chris Laprise, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Jun 06, 2017 at 06:42:59PM -0400, Chris Laprise wrote:
> Per
> https://github.com/tasket/Qubes-VM-hardening/issues/7#issuecomment-306637475
>
> If a Qubes startup service (in this case, qubes-mount-dirs) fails, there is
> no GUI after startup, even though the other services seem to have started
> OK.
>
> I am looking for a way to have the VM notify the user when one of its
> startup services fail.

If things fails before starting any of qrexec-agent and gui-agent, there
is no simple way to communicate it to the user (other than displaying
something on console and hoping user will eventually call xl console
...). Both are ordered after mounting /rw.
But once you have qrexec-agent, you can use some qrexec service -
another use case for https://github.com/QubesOS/qubes-issues/issues/889

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

iQEcBAEBCAAGBQJZNzjRAAoJENuP0xzK19cs0HcIAIdPTfGeQzGfRKkO3wMpMS38
fwMD7El5rBX/uxPDZILlQY9ogSaDfbJ0V6l0Y9N5s0vildogaSqUg97Wr7ul7mLG
W2+Us43I9DYILbWs+58JEJfITJ4QiGbIRoV5zPoeG6rOg1OvTSAssVvS0d0fI0XO
8RLuDcxRtM6T/90nWJvvaJj9l5tfwu1ofQovyENA7GZ070WtqbVXBs51MsgudT2L
JLr62WBAMSIVS1xz6ATYZvXWH5kZgHs0wxS6pzI0Yc2No2Xh9P9jkLSLykvy6rHr
T+malR5QDnXq+zy07kEjUV2JBm5eFGYjYidIXgJJXrpN5dNklXlKMEMTocTFG9I=
=9m6C
-----END PGP SIGNATURE-----

Chris Laprise

unread,
Jun 13, 2017, 5:09:54 PM6/13/17
to Marek Marczykowski-Górecki, qubes...@googlegroups.com
On 06/06/2017 07:20 PM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Tue, Jun 06, 2017 at 06:42:59PM -0400, Chris Laprise wrote:
>> Per
>> https://github.com/tasket/Qubes-VM-hardening/issues/7#issuecomment-306637475
>>
>> If a Qubes startup service (in this case, qubes-mount-dirs) fails, there is
>> no GUI after startup, even though the other services seem to have started
>> OK.
>>
>> I am looking for a way to have the VM notify the user when one of its
>> startup services fail.
>
> If things fails before starting any of qrexec-agent and gui-agent, there
> is no simple way to communicate it to the user (other than displaying
> something on console and hoping user will eventually call xl console
> ...). Both are ordered after mounting /rw.
> But once you have qrexec-agent, you can use some qrexec service -
> another use case for https://github.com/QubesOS/qubes-issues/issues/889
>

I'm a bit uncomfortable with that proposal, because qubes-gui is the
focal point of security context. From my perspective, creating another
UI channel could water-down the strong sense of context that qubes-gui
delivers. And it means context has to be guarded in an additional component.

My preference would be to make qubes-gui more robust under different
conditions and/or limiting the text-based role to the specific case of
having QubesVm.start() check VM boot status.
Reply all
Reply to author
Forward
0 new messages