Re: Jailing {open,}ntpd
On 06/27/2018 23:08, Thomas Steen Rasmussen wrote: 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. ___ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: Jailing {open,}ntpd
On 06/26/2018 09:53 PM, Roger Marquis wrote:
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
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: Jailing {open,}ntpd
On 27/06/2018 1:17 PM, Dewayne Geraghty wrote: > 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. ___ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: Jailing {open,}ntpd
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. ___ freebsd-jail@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Re: Jailing {open,}ntpd
Why not with according devfs rules?
>Вторник, 26 июня 2018, 23:00 +03:00 от 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
>___
>freebsd-secur...@freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-security
>To unsubscribe, send any mail to " freebsd-security-unsubscr...@freebsd.org "
С уважением,
John Freeman
quak...@mail.ru
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
Jailing {open,}ntpd
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
___
freebsd-jail@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"
