[clug] sys-time in LXC guest [Was: QubesOS event channels clarification [Was: Re: Canberra Linux Users Group Meeting - 23 July 2015]]
Robert.Edwards at anu.edu.au
Mon Jul 27 23:26:58 UTC 2015
Just to follow up on this thread and report that I have found how to
persuade the Debian Jessie LXC host to not drop "sys-time" capability
(the default setting in Debian) for one guest container, and now I am
running NTP in a guest, which means my host container not longer has
any need for an external internet connection. Yay! Seems trivial in
Thanks for your help, Paul.
On 27/07/15 08:51, Bob Edwards wrote:
> 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
>> 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.
> Many thanks,
> Bob Edwards.
>>> 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