Discussion:
Jailing {open,}ntpd
Roger Marquis
2018-06-26 19:53:08 UTC
Permalink
Has anyone configured {open,}ntpd to run in a FreeBSD jail or Linux
container? Can it be done in such a way that a breached daemon would
not have access to the host?

Roger Marquis
John Freeman via freebsd-jail
2018-06-26 20:47:52 UTC
Permalink
Why not with according devfs rules?
Post by Roger Marquis
Has anyone configured {open,}ntpd to run in a FreeBSD jail or Linux
container? Can it be done in such a way that a breached daemon would
not have access to the host?
Roger Marquis
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-security
С уважением,
John Freeman
***@mail.ru
Dewayne Geraghty
2018-06-27 03:17:46 UTC
Permalink
Hi Roger, I have a similar mental state :)

Yes, I run ports ntpd within a chroot environment. 

ntpd can run within a jail, but it lacks the priv to perform a syscall
to modify time.  Which is correct behaviour, for a restricted
environment; protecting other jailed environs.  Previously there was
also an mlock call, which prevented it running but that was changed a
while ago; but that's an aside unless you're running on old "stuff". ;)

As this is not a security issue, I've removed those interested in that
area from the CC.

There are a few tricks with chroot, but first a disclaimer: I use jails
for everything except ntpd, so there may be a better way.

Trick 1. This is how I want ntpd to run

/usr/local/sbin/ntpd -c /etc/ntp.conf -x -G -g -p /var/run/ntpd.pid

but you can't pass arguments into chroot.  So I created a "/start" that
I place my chroot commands into.

Trick 2.  Use ldd to see what libs you need to copy into your chroot. 
Also remember, that you must have ld-elf and /dev/null. So

Using ROOTD as your chroot destination

mkdir $ROOTD/libexec && cp /libexec/ld-elf.so.1 $ROOTD/libexec  ;

and setup dev

  mkdir  $ROOTD/dev
  touch $ROOTD/dev/null
  chmod 666 $ROOTD/dev/null;   # Yes this is sufficient!

The rest of the files are from the ntpd tarfile.  Enjoy ;)

PS: ntpq wont report due to "servname not supported for ai_socktype"...
no solution yet.
Dewayne Geraghty
2018-06-27 04:13:02 UTC
Permalink
Post by Dewayne Geraghty
Hi Roger, I have a similar mental state :)
Yes, I run ports ntpd within a chroot environment. 
ntpd can run within a jail, but it lacks the priv to perform a syscall
to modify time.  Which is correct behaviour, for a restricted
environment; protecting other jailed environs.  Previously there was
also an mlock call, which prevented it running but that was changed a
while ago; but that's an aside unless you're running on old "stuff". ;)
As this is not a security issue, I've removed those interested in that
area from the CC.
There are a few tricks with chroot, but first a disclaimer: I use jails
for everything except ntpd, so there may be a better way.
Trick 1. This is how I want ntpd to run
/usr/local/sbin/ntpd -c /etc/ntp.conf -x -G -g -p /var/run/ntpd.pid
but you can't pass arguments into chroot.  So I created a "/start" that
I place my chroot commands into.
Trick 2.  Use ldd to see what libs you need to copy into your chroot. 
Also remember, that you must have ld-elf and /dev/null. So
Using ROOTD as your chroot destination
mkdir $ROOTD/libexec && cp /libexec/ld-elf.so.1 $ROOTD/libexec  ;
and setup dev
  mkdir  $ROOTD/dev
  touch $ROOTD/dev/null
  chmod 666 $ROOTD/dev/null;   # Yes this is sufficient!
The rest of the files are from the ntpd tarfile.  Enjoy ;)
PS: ntpq wont report due to "servname not supported for ai_socktype"...
no solution yet.
Oops.  Running on low memory.
Roger, forget trick 1 above, we run our ntp via
chroot /usr/chroot/ntp /usr/local/sbin/ntpd -c /etc/ntp.conf -x -G -g -p
/var/run/ntpd.pid
and yes, "ntpq -np 127.0.0.1" works from the base system.  Tsk.
Thomas Steen Rasmussen
2018-06-28 06:08:12 UTC
Permalink
Post by Roger Marquis
Has anyone configured {open,}ntpd to run in a FreeBSD jail or Linux
container?  Can it be done in such a way that a breached daemon would
not have access to the host?
Roger Marquis
Hello,

TL;DR: +1

I've been wondering about the same thing.

Anything that speaks to untrusted network clients belongs in a jail, but
to my knowledge both ntpds are unjailable because they want to use some
kernel system calls (to adjust time) which are not allowed in jails (as
it should be).

In my opinion adjusting the local bios/cmos clock and keeping it in sync
with some upstream NTP source is a different task than serving NTP to
untrusted network clients (like an ISP is expected to do).

I'd love for one or both ntpds to have an option to only serve local
time, without attempting to adjust the clock, if such a feature is possible.

I'd then keep an ntpd running in the base system which takes care of
keeping the system clock in-sync, and another in a jail which only reads
the time and serves it to network clients, but doesn't try to adjust or
speak to upsteam NTPs.

I will be watching this thread hoping that someone who knows about NTP
will chime in. Thanks!


Best regards,

Thomas Steen Rasmussen
Mel Pilgrim
2018-06-28 12:02:12 UTC
Permalink
Post by Thomas Steen Rasmussen
Anything that speaks to untrusted network clients belongs in a jail, but
to my knowledge both ntpds are unjailable because they want to use some
kernel system calls (to adjust time) which are not allowed in jails (as
it should be).
In my opinion adjusting the local bios/cmos clock and keeping it in sync
with some upstream NTP source is a different task than serving NTP to
untrusted network clients (like an ISP is expected to do).
I'd love for one or both ntpds to have an option to only serve local
time, without attempting to adjust the clock, if such a feature is possible.
I'd then keep an ntpd running in the base system which takes care of
keeping the system clock in-sync, and another in a jail which only reads
the time and serves it to network clients, but doesn't try to adjust or
speak to upsteam NTPs.
You can do this by configuring the jailed ntpd with the local clock
driver as a reference. Doing this for an ntpd serving the general
public would be evil. NTP Pool Project membership prohibits using the
local clock driver.

If your priority is something with a better security profile than an ISC
daemon, run OpenNTPD instead.

For the ISC ntpd, configure a reference clock with a server line that
has a magic number 127.127.0.0/16 address. The "Reference Clock
Support" section of ntp.conf(5) has more details. The local clock is
type 1.

OpenNTPD does not have reference clock support.

Loading...