Solved Running an NTP time server in a jail?

[subnetspider]

Hello everyone,

I'm currently trying to migrate more and more of my network services into jails, mainly for learning as well as decentralization.
Now I'd also like to run NTP servers in a few jails, but I don't know if that's even possible since jails use the time of the host's kernel.
In addition, the jail hosts are currently virtual machines whose system clocks have a lot of jitter from what I've heard.
I've read the ntpd(8) man page and also looked at OpenNTPD and Chrony, but haven't really figured out if what I'm trying to achieve makes sense...

Does it make sense to run an NTP server in a jail inside a virtual machine, or should I rather use something like a Raspberry Pi or a thin client instead?

 

[algi]

Jails are not virtual machines, they use the same kernel as the system does, so they also share the same time. There's no benefit (IMHO) of running ntpd in jail as it has to access kernel anyway, which defeats any benefits of jail, unless I'm missing something here.

 

[zirias@]

Does it make sense to run an NTP server in a jail inside a virtual machine

Whether it makes sense, you decide. ntpd(8) certainly runs in a jail, but can't modify the local computer's time.

I personally run it on both the host AND inside one jail. On the host, it's configured to use the pool to sync to and only allow connections from that one jail. In the jail, it's configured to sync to the one instance running directly on the host.

At least that way, clients (including possible guests in my network) only ever talk to a jailed instance. It's not a perfect solution because the instance running directly on the host still has to trust all the pool servers

Jails are not virtual machines, they use the same kernel as the system does, so they also share the same time.

The term "virtual machine" isn't necessarily that restrictive, a concept like (VNET) jails is often called a "userspace vm".

There's no benefit (IMHO) of running ntpd in jail as it has to access kernel anyway, which defeats any benefits of jail, unless I'm missing something here.

I'd argue that's the wrong way around. It can't adjust the clock when running in a jail, limiting its functionality. It might still make sense to isolate any network service though ....

 

[subnetspider]

Jails are not virtual machines, they use the same kernel as the system does, so they also share the same time. There's no benefit (IMHO) of running ntpd in jail as it has to access kernel anyway, which defeats any benefits of jail, unless I'm missing something here.

Correct, but my jails are running inside of a FreeBSD virtual machines on Proxmox VE servers.

I'd argue that's the wrong way around. It can't adjust the clock when running in a jail, limiting its functionality. It might still make sense to isolate any network service though ....

Exactly my thought, isolation is great unless it limits functionality.

I think I'll try anyway, but keep my expectations low.

 

[zirias@]

Exactly my thought, isolation is great unless it limits functionality.

Well, it certainly does here. And if you run it only in the jail, once the drift to the local clock that can't be adjusted that way gets too large, it will start to fail.

That's why I opted for that compromise, the instance running directly on the host will keep the local machine's time correct, the instance in the jail is the one serving all the clients. As I said, it's not perfect, but it works for me

 

[algi]

I agree here with zirias@ that securing the ntpd source is quite problematic and it might open door to a potential attack via providing wrong time. That's why I prefer to use OpenNTPD (from OpenBSD). It allows you to set constraints, which verifies the time provided by NTP servers by querying other hosts.

I also like the "paranoid" approach of isolating ntpd server in jail because it's a network service and querying the time from the "outside" of the jail (from the host machine). That's pretty clever and brings a benefit. Thanks for sharing!

 

[zirias@]

That's pretty clever and brings a benefit.

Thanks! But I'd like to reiterate it's only a "partial solution", the instance on the host (not jailed) still has to communicate with the "upstream" servers, which could of course potentially open attack vectors... therefore

That's why I prefer to use OpenNTPD (from OpenBSD). It allows you to set constraints, which verifies the time provided by NTP servers by querying other hosts.

this sounds interesting as well, I'll have a look at least this seems to counteract one possible type of attacks.

 

[IAmPaigeAT]

Hello everyone,

I'm currently trying to migrate more and more of my network services into jails, mainly for learning as well as decentralization.
Now I'd also like to run NTP servers in a few jails, but I don't know if that's even possible since jails use the time of the host's kernel.
In addition, the jail hosts are currently virtual machines whose system clocks have a lot of jitter from what I've heard.
I've read the ntpd(8) man page and also looked at OpenNTPD and Chrony, but haven't really figured out if what I'm trying to achieve makes sense...

Does it make sense to run an NTP server in a jail inside a virtual machine, or should I rather use something like a Raspberry Pi or a thin client instead?

ntp_adjtime: Operation not permitted

If you cant white list system calls I'm just gonna take a guess that ipsec-tools isn't work either which sucks.

Further Configuration​

Fine tuning of a jail’s configuration is mostly done by setting sysctl(8) variables. Here is a list of the main jail-related sysctls, complete with their default value. Please refer to the jail(8) and sysctl(8) manual pages for more information on each variable.

• security.jail.set_hostname_allowed: 1
• security.jail.socket_unixiproute_only: 1
• security.jail.sysvipc_allowed: 0
• security.jail.enforce_statfs: 2
• security.jail.allow_raw_sockets: 0
• security.jail.chflags_allowed: 0
• security.jail.jailed: 0

that's not even a complete list

security.jail.mount_nullfs_allowed: 0
security.jail.vmm_allowed: 0
security.jail.mount_linsysfs_allowed: 0
security.jail.mount_linprocfs_allowed: 0
security.jail.mount_fdescfs_allowed: 0
security.jail.mount_zfs_allowed: 0
security.jail.mount_tmpfs_allowed: 0
security.jail.mount_procfs_allowed: 0
security.jail.mount_devfs_allowed: 0
security.jail.param.linux.oss_version: 0
security.jail.param.linux.osrelease: 65
security.jail.param.linux.osname: 65
security.jail.param.linux.: 0
security.jail.param.zfs.mount_snapshot: 0
security.jail.param.zfs.: 0
security.jail.param.sysvshm.: 0
security.jail.param.sysvsem.: 0
security.jail.param.sysvmsg.: 0
security.jail.param.allow.vmm: 0
security.jail.param.allow.mount.nullfs: 0
security.jail.param.allow.mount.linsysfs: 0
security.jail.param.allow.mount.linprocfs: 0
security.jail.param.allow.mount.fdescfs: 0
security.jail.param.allow.mount.zfs: 0
security.jail.param.allow.mount.tmpfs: 0
security.jail.param.allow.mount.procfs: 0
security.jail.param.allow.mount.devfs: 0
security.jail.param.allow.mount.: 0
security.jail.param.allow.nfsd: 0
security.jail.param.allow.suser: 0
security.jail.param.allow.unprivileged_proc_debug: 0
security.jail.param.allow.read_msgbuf: 0
security.jail.param.allow.reserved_ports: 0
security.jail.param.allow.mlock: 0
security.jail.param.allow.socket_af: 0
security.jail.param.allow.quotas: 0
security.jail.param.allow.chflags: 0
security.jail.param.allow.raw_sockets: 0
security.jail.param.allow.sysvipc: 0
security.jail.param.allow.set_hostname: 0
security.jail.param.ip6.saddrsel: 0
security.jail.param.ip6.: 0
security.jail.param.ip4.saddrsel: 0
security.jail.param.ip4.: 0
security.jail.param.cpuset.id: 0
security.jail.param.host.hostid: 0
security.jail.param.host.hostuuid: 64
security.jail.param.host.domainname: 256
security.jail.param.host.hostname: 256
security.jail.param.host.: 0
security.jail.param.children.max: 0
security.jail.param.children.cur: 0
security.jail.param.dying: 0
security.jail.param.vnet: 0
security.jail.param.persist: 0
security.jail.param.devfs_ruleset: 0
security.jail.param.enforce_statfs: 0
security.jail.param.osrelease: 32
security.jail.param.osreldate: 0
security.jail.param.securelevel: 0
security.jail.param.path: 1024
security.jail.param.name: 256
security.jail.param.parent: 0
security.jail.param.jid: 0
security.jail.children.cur: 6
security.jail.children.max: 999999
security.jail.devfs_ruleset: 0
security.jail.enforce_statfs: 2
security.jail.mlock_allowed: 0
security.jail.mount_allowed: 0
security.jail.chflags_allowed: 0
security.jail.allow_raw_sockets: 1
security.jail.sysvipc_allowed: 0
security.jail.socket_unixiproute_only: 1
security.jail.set_hostname_allowed: 1
security.jail.jail_max_af_ips: 255
security.jail.vnet: 0
security.jail.jailed: 0

Whether it makes sense, you decide. ntpd(8) certainly runs in a jail, but can't modify the local computer's time.

I don't see any reason why it couldn't be though. You can optionally do lots of stuff but then again, just looking at it first hand it looks like all of the options for it are all or none (jails) which sucks.