Monday, April 4, 2011

How to chroot ntp in Debian

Here are few simple steps to chroot ntp in debian. Add the following to file /usr/local/sbin/chroot-ntp and execute (alternatively you can download script from bitbucket site here):
#!/bin/bash

/etc/init.d/ntp stop

rootfs=/var/chroot/ntp
mkdir -p $rootfs/{etc,var/lib/ntp,var/log}

mv /etc/ntp.conf $rootfs/etc
ln -s $rootfs/etc/ntp.conf /etc/ntp.conf

if [ -e /var/lib/ntp/ntp.drift ]; then
    mv /var/lib/ntp/ntp.drift $rootfs/var/lib/ntp
fi
ln -s $rootfs/var/lib/ntp/ntp.drift \
    /var/lib/ntp/ntp.drift
chown -R ntp:ntp $rootfs/var/lib/ntp

mv /var/log/ntpstats $rootfs/var/log
ln -s $rootfs/var/log/ntpstats /var/log/ntpstats
chown -R ntp:ntp $rootfs/var/log/ntpstats

sed -e "s,'-g','-4 -i /var/chroot/ntp -g'," \
    /etc/default/ntp > /tmp/x && \
    mv /tmp/x /etc/default/ntp

sed -e "s,restrict -6,#restrict -6," \
    -e "s,restrict ::1,#restrict ::1," \
    /etc/ntp.conf > /tmp/x && \
    mv /tmp/x /etc/ntp.conf

/etc/init.d/ntp start
Verify that ntp uses the chroot (file /etc/default/ntp):
NTPD_OPTS='-4 -i /var/chroot/ntp -g'

10 comments :

  1. Thanks for the nice How To.

    Can it be that the /var/chroot/ntp/var/run directory is not used, since the PID is still prepared in /var/run/ntpd.pid (ouside of the chroot). I wonder if I can remove it again?

    When using the drift file, you should also create a directory under /var/chroot/ntp/var/lib/ntp. Owner must be ntp.

    Have you made ​​any modifications to the /etc/init.d/ntp script?

    I'm using Debian Squeeze.

    Thanks.
    Marc

    ReplyDelete
  2. Thank you for your questions. I am using Debian Testing and at the moment it is not far away from Squeeze.

    1. Yes, /var/chroot/ntp/var/run is not used since ntp pid file is controlled during ntp daemon start.

    2. I have modified the script a bit to take drift file into account.

    3. There are no any modifications necessary in /etc/init.d/ntp script.

    ReplyDelete
  3. Quick question for you,

    Prior to running this script I was able to use ntpq -p to check the status of NTP. After running this script I get:

    localhost: timed out, nothing received
    ***Request timed out

    My clients all still appear to be sync'd and when I run ntptrace I get a result back. Is this expected behaviour?

    ReplyDelete
    Replies
    1. When no host is specified to `ntpq -p` command it tries communicate to localhost. There are certain restrictions in /etc/ntp.conf file. Take a look at line related to 127.0.0.1 interface... if you have that line commented out than you get exactly the behavior you experienced.

      Delete
    2. ntp.conf has restrict 127.0.0.1 in it and not commented out. As I mentioned, prior to applying your script it worked fine. When I specify eth0 as a host, you are correct, it connects fine so this appears to be something to do with accessing the loopback interface afer the chroot. Thanks for your help and a great blog.

      Delete
  4. I've seen ntpd do the same thing with the loopback adapter when using the "i" option to jail the daemon. When I look at the log file, I see the daemon deleting both the lo and eth0/ipv6 interfaces. eth0/ipv4 still seems to work. I have found that if I mount the /proc filesystem in the jail as /proc this does not happen. Mounting proc in the jail varies from "okay" to "don't do it" depending on who you read. To be safe, until I can learn more about the ramifications of mounting /proc in the jail, I leave it unmounted and just specify the loopback address with "ntpq -p 127.0.0.1". Specifying the loopback address seems to work, even though the daemon logs that it is deleting the interface. Strange.

    ReplyDelete
  5. An update to my previous post about mounting the proc filesystem in the jail... It seems when ntp is built with ipv6 enabled, the ntpq app gives preference to the ipv6 loopbak (::1) unless told otherwise with an ipv4 address (127.0.0.1) or the -4 command line parameter. Likewise when starting ntpd it will log messages about deleting any ipv6 addresses it finds, unless proc is mounted. It therefore will not listen on any ipv6 addresses without proc. Logically, it follows why ntpq fails unless specifically told to use ipv4. Found a link @ ISC that says the ipv6 stack developers have not made it possible to scan interfaces (and maybe bind) without the used of the filesystem (proc). This differs from how the ipv4 stack works and fits in with what I'm seeing with mounting /proc. An alternative is to use --disable-ipv6 when running configure to build ntp. This forces the binaries (ntpq) into using ipv4 only and remove support for ipv6. If enabling ipv6 is important, you therefore must mount /proc in the ntp jail or try an alternative in the link that is to cat the contents of a file in /proc to into same named file in the jails proc. This assumes a static ipv6 configuration. However, if handled in the init script, it just might work and permit the usage of ipv6 in the jail without making the entire proc filesystem available when having ipv6 support is important.

    Hope this helps someone,

    Barry

    https://lists.isc.org/pipermail/bind-users/2004-October/052976.html

    ReplyDelete
  6. Cat-ing the contents of /proc/net/if_inet6 to /path/to/jail/proc/net/if_inet6 DOES allow ntpd to remain active on ipv6 interfaces after the chroot occurs without mounting the proc filesystem in the jail. This will allow you to compile with built in ipv6 support and have the daemon actually listen on the available interfaces. Likewise, after creating this file, the ntpq app behaves just as it did before jailing the daemon.

    Barry

    ReplyDelete
  7. At what point does NTPD do its chrooting? It seems as if it tries to read the conf file first before it drops to non-root and Chroort's. as my ntpd can't find the ntpd.conf unless its in the /etc/ntp.conf spot, or I tell it where its at in the jail.

    ReplyDelete