[clug] QubesOS event channels clarification [Was: Re: Canberra Linux Users Group Meeting - 23 July 2015]

Paul Harvey csirac2 at gmail.com
Sun Jul 26 13:31:51 UTC 2015


Hi Bob,

On 26 July 2015 at 23:10, Bob Edwards <Robert.Edwards at anu.edu.au> wrote:
> On 25/07/15 00:32, Paul Harvey wrote:
>>
>> Thanks everybody for coming to the talk and asking great questions!
>>
>
> Thanks for your excellent talk on Thursday, Paul, and your extensive
> follow-up - much appreciated.
>
> One question I had was how QubesOS deals with network time protocol
> (NTP) as Dom0 has no network connectivity. As each AppVM has it's
> own kernel, I am guessing that there is either an NTP server on each
> AppVM, or this Xen message passing system is being used to set time
> across the domains somehow?

According to https://www.qubes-os.org/doc/Dom0Tools/QvmService/:
"By default Qubes calls ntpdate every 6 minutes in selected VM (aka
ClockVM), then propagate the result using qrexec calls"

qrexec is a tool in dom0 which executes commands in a given domU VM.
Documentation for qrexec is at https://www.qubes-os.org/doc/Qrexec/

qrexec works using the Xen event channel/shared-memory feature discussed.

By default I believe the ntp client is executed in the NetVM (running
the NIC drivers).

> <going somewhat off-topic...>
> The main reason I ask is that I have been inspired to work further
> on my LXC compartmentalisation on various boxen I look after. I now
> aspire to have the host container have no external network.
>
> Alas, ntpd is tripping me up. It needs to run on the host container
> in order to modify the kernel system time, but also needs to be able
> to contact externally networked time sources. Usually, I allow the
> host container to have limited external network access via SNAT,
> specifically for this purpose.
>
> OpenVZ solves this by allowing a specific (guest) container to have
> access to the kernel resources required to modify the system time.
> I can't find anything that aludes to allowing an LXC container to
> have similar access.

You can do a similar thing which you've described OpenVZ does by
granting CAP_SYS_TIME (and perhaps others) to the guest container
which needs to manipulate the time of the host's kernel.

In docker this would be something like docker run --cap-add=cap_sys_time

I'm afraid I don't use lxc directly, but Docker's documentation for
this is at https://docs.docker.com/reference/run/#runtime-privilege-linux-capabilities-and-lxc-configuration

man 7 capabilities has (hopefully) the full list of capabilities
supported by your kernel

> Another variation (to SNAT) would be to have a UDP proxy running on
> the external internet facing container and proxy the NTP requests
> from the host container. Could be a bit "safer" than doing it with
> SNAT, but then again, could introduce further vulnerabilities.

I'd bet you could configure an LXC container to do what OpenVZ does by
just figuring out how to grant the cap_sys_time capability.

Hope that helps!

--
Paul

> Anyone read this far and have any ideas? And I would be interested
> to know how QubesOS solves the equivalent problem for Dom0.
>
> cheers,
>
> Bob Edwards.
>
> --
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux



More information about the linux mailing list