Re: Jailing {open,}ntpd

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Jailing {open,}ntpd

freebsd-jail mailing list

Why not with according devfs rules?

>Вторник, 26 июня 2018, 23:00 +03:00 от Roger Marquis <[hidden email]>:
>
>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
>_______________________________________________
>[hidden email] mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-security
>To unsubscribe, send any mail to " [hidden email] "


С уважением,
John Freeman
[hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Jailing {open,}ntpd

Dewayne Geraghty-4
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.

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Jailing {open,}ntpd

Dewayne Geraghty-4
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.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Jailing {open,}ntpd

Thomas Steen Rasmussen-3
In reply to this post by freebsd-jail mailing list
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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Jailing {open,}ntpd

Mel Pilgrim
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.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "[hidden email]"