[clug] sys-time in LXC guest [Was: QubesOS event channels clarification [Was: Re: Canberra Linux Users Group Meeting - 23 July 2015]]

Paul Harvey csirac2 at gmail.com
Tue Jul 28 00:12:32 UTC 2015


Good to hear! I've only in the last couple of years become aware of
capabilities and actually scratching the surface of how linux
containers work myself.

Now if you want to really brace yourself for the real design decisions
behind systemd, the future and perhaps the end of general purpose
computing environments as we know it, try this:

http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html


On 28 July 2015 at 09:26, Bob Edwards <Robert.Edwards at anu.edu.au> wrote:
>
> 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
> the end.
>
> Thanks for your help, Paul.
>
> Bob Edwards.
>
> 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
>>>
>>> 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.
>>
>> 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!
>>>
>>> --
>>> 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
>>
>>
>>
>
>
> --
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux



More information about the linux mailing list