[clug] QubesOS event channels clarification [Was: Re: Canberra Linux Users Group Meeting - 23 July 2015]
Robert.Edwards at anu.edu.au
Sun Jul 26 22:51:07 UTC 2015
On 26/07/15 23:31, Paul Harvey wrote:
> 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).
Great - thanks for the explanation and the link.
>> <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
I think you're right, and I hadn't thought to look up how docker
does it. Thanks for the tip - I'll investigate what LXC can do with
capabilities for me here.
>> 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!
>> Anyone read this far and have any ideas? And I would be interested
>> to know how QubesOS solves the equivalent problem for Dom0.
>> Bob Edwards.
>> linux mailing list
>> linux at lists.samba.org
More information about the linux