1. Forum
  2. Usenet
  3. COMP.PROTOCOLS.TIME.NTP

  • Re: Aborting ntpd when unable to control the clock

    From Terje Mathisen@21:1/5 to Dave Hart on Wed Nov 13 12:13:05 2024
    To: hackers@lists.ntp.org (NTP coders)
    To: questions@lists.ntp.org

    This is a multi-part message in MIME format.
    Dave Hart wrote:
    It seems obvious to me that ntpd should log an error and terminate
    when it is unable to adjust the system clock.  To my surprise, https://bugs.ntp.org/1433 pointed out that when a Linux ntpd binary
    built to use capabilities is run on a kernel build without capability capability, ntpd blithely runs without complaint while effectively
    doing nothing.  For this specific problem, you could blame the user
    and say they need to use ntpd built --without-linux-caps, but there's
    a more general issue of ntpd not reporting let alone aborting on a
    failure to control the clock.

    To explain the context a bit, I came across bug 1433 somehow and saw
    that in 2019 the decade-old bug was fixed by having ntpd test for
    whether capabilities work before dropping root (they're needed to
    crank the clock when not running as root on Linux).  When capabilities
    do not work, ntpd was then ignoring the request to drop root and run
    as a user, typically "ntp".  This meant it was silently opening up an opportunity for more useful privilege elevation or remote code
    execution despite the user's explicit configuration, and that's
    unacceptable to me.  My intention is to change the behavior to error
    out when controlling the clock fails (via step or slew).  If you think that's a bad idea, please speak up and explain your reasoning.

    Cheers,
    Dave Hart
    I agree, that seems like The Right Thing to do.

    Terje
    PS. I'm going to retire soon, so my intention is to get back into NTP
    Hackers work at that point!

    --
    - <Terje@tmsw.no>
    "almost all programming can be viewed as an exercise in caching"


    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Dave Hart wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAMbSiYDb+wETmibMR4QauyQ9d3aRGUtRr011U3rnsuwea_HXeA@mail.gmail.com">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <div dir="ltr">
    <div dir="ltr">
    <div class="gmail_default" style="font-family:trebuchet
    ms,sans-serif">It seems obvious to me that ntpd should log
    an error and terminate when it is unable to adjust the
    system clock.  To my surprise, <a
    href="https://bugs.ntp.org/1433" target="_blank"
    moz-do-not-send="true">https://bugs.ntp.org/1433</a>
    pointed out
  • From Majdi S. Abbas@21:1/5 to Dave Hart on Thu Nov 14 02:38:00 2024
    Copy: hackers@lists.ntp.org (NTP coders)
    Copy: questions@lists.ntp.org

    On Tue, Nov 12, 2024 at 07:10:12PM +0000, Dave Hart wrote:
    It seems obvious to me that ntpd should log an error and terminate when it
    is unable to adjust the system clock. To my surprise, https://bugs.ntp.org/1433 pointed out that when a Linux ntpd binary built
    to use capabilities is run on a kernel build without capability capability, ntpd blithely runs without complaint while effectively doing nothing. For this specific problem, you could blame the user and say they need to use
    ntpd built --without-linux-caps, but there's a more general issue of ntpd
    not reporting let alone aborting on a failure to control the clock.

    Note that widely used operating systems, like Apple's OS X, run
    ntpd as a monitoring service that explicitly does not/cannot discipline
    the clock.

    I've also heard of people explicitly running ntpd to monitor and
    log statistics, without wanting it to discipline the clock.

    Perhaps the cleanest way to do this is add a flag to run the
    daemon without attempting to discipline the clock?

    --msa

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harlan Stenn via questions Mailing@21:1/5 to Dave Hart on Thu Nov 14 07:13:00 2024
    To: msa@latt.net (Majdi S. Abbas)
    Copy: hackers@lists.ntp.org (NTP coders)
    Copy: questions@lists.ntp.org

    On 11/13/2024 6:35 PM, Dave Hart wrote:
    On Thu, Nov 14, 2024 at 2:31 AM Majdi S. Abbas <msa@latt.net <mailto:msa@latt.net>> wrote:

    On Tue, Nov 12, 2024 at 07:10:12PM +0000, Dave Hart wrote:
    > It seems obvious to me that ntpd should log an error and
    terminate when it
    > is unable to adjust the system clock.  To my surprise,
    > https://bugs.ntp.org/1433 <https://bugs.ntp.org/1433> pointed out
    that when a Linux ntpd binary built
    > to use capabilities is run on a kernel build without capability
    capability,
    > ntpd blithely runs without complaint while effectively doing
    nothing.  For
    > this specific problem, you could blame the user and say they need
    to use
    > ntpd built --without-linux-caps, but there's a more general issue
    of ntpd
    > not reporting let alone aborting on a failure to control the clock.

            Note that widely used operating systems, like Apple's OS X, run
    ntpd as a monitoring service that explicitly does not/cannot discipline
    the clock.

            I've also heard of people explicitly running ntpd to
    monitor and
    log statistics, without wanting it to discipline the clock.

            Perhaps the cleanest way to do this is add a flag to run the
    daemon without attempting to discipline the clock?


    I believe that flag is already there, "disable ntp".  I haven't used it though.

    To be clear, deciding when ntpd should abort if it cannot discipline the
    clock should be done at the "right" place in the code - not too early,
    and not too late.

    Cheers,
    Dave Hart


    --
    Harlan Stenn <stenn@nwtime.org>
    https://www.nwtime.org/ - be a member!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)