In message <c256aafe-27c0-403e-9089-554bfe9f4...@plan-b.pwste.edu.pl>, Marek Za rychta writes: > This is a multi-part message in MIME format. > --------------DOa45fOEFt3RPa3J3HNcRaVj > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 8bit > > W dniu 11.03.2025 o 20:06, Cy Schubert pisze: > > In message<2ac849e6-3851-47ad-9844-968cf0067...@plan-b.pwste.edu.pl>, > > Marek Za > > rychta writes: > >> W dniu 11.03.2025 o 19:02, Cy Schubert pisze: > >>> In message<9756f69e-c849-4a01-b7c0-4b89a57e1...@plan-b.pwste.edu.pl>, > >>> Marek Za > >>> rychta writes: > >>>> This is a multi-part message in MIME format. > >>>> --------------AE7s5oJnhOW0uW76c0IQR0yC > >>>> Content-Type: text/plain; charset=UTF-8; format=flowed > >>>> Content-Transfer-Encoding: 8bit > >>>> > >>>> W dniu 11.03.2025 o 18:20, Cy Schubert pisze: > >>>>> In message<f63d67b5-6e05-481f-9560-06150eb5a...@plan-b.pwste.edu.pl>, > >>>>> Marek Za > >>>>> rychta writes: > >>>>>> W dniu 11.03.2025 o 17:29, Marek Zarychta pisze: > >>>>>>> W dniu 11.03.2025 o 16:13, Cy Schubert pisze: > >>>>>>>> In message<20250311011257.dd642ecbcd132ecb7142d...@dec.sakura.ne.jp> > , > >>>>>>>> Tomoaki > >>>>>>>> AOKI writes: > >>>>>>>>> On Mon, 10 Mar 2025 16:37:58 +0100 > >>>>>>>>> "Herbert J. Skuhra"<herb...@gojira.at> wrote: > >>>>>>>>> > >>>>>>>>>> On Mon, 10 Mar 2025 13:06:25 +0100, David Wolfskill wrote: > >>>>>>>>>>> On Mon, Mar 10, 2025 at 01:51:40PM +0200, Marek Zarychta wrote: > >>>>>>>>>>>> Hello List Subscirbers, > >>>>>>>>>>>> > >>>>>>>>>>>> in the past the module was loaded automatically upon NTPD server > >>>>>>>>>>>> startu > >>>>>>>>> p. > >>>>>>>>>>>> It's no longer true, now it has to be loaded earlier. > >>>>>>>>>>>> Perhaps people running stable/14 might find this message useful. > >>>>>>>>>> Hmm, works for me on main and stable/14. > >>>>>>>>>> > >>>>>>>>>>> So... I noticed this for (precisely) one of the five machines I h > av > >> e > >>>>>>>>>>> that track stable/14 -- the other 4 get mac_ntpd loaded > >>>>>>>>>>> automagically as > >>>>>>>>>>> usual. > >>>>>>>>>>> > >>>>>>>>>>> In the failing case, it seems that > >>>>>>>>>>> > >>>>>>>>>>> sysctl security.mac.version > >>>>>>>>>>> > >>>>>>>>>>> yielded > >>>>>>>>>>> > >>>>>>>>>>> sysctl: unknown oid 'security.mac.version' > >>>>>>>>>> I only get this if I build a kernel without "options MAC". But in > th > >> is > >>>>>>>>>> no mac_* kernel modules are built and ntpd fails with: > >>>>>>>>>> > >>>>>>>>>> Starting ntpd. > >>>>>>>>>> daemon control: got EOF > >>>>>>>>>> /etc/rc.d/ntpd: WARNING: failed to start ntpd > >>>>>>>>> In this case, you'll find something like > >>>>>>>>> Need MAC 'ntpd' policy enabled to drop root privileges > >>>>>>>>> daemon child exited with code 255 > >>>>>>>>> in ntpd logfile (/var/db/ntpd.log in my case, but > >>>>>>>>> possibly /var/log/messages by default). > >>>>>>>> I don't understand why some systems (those in this thread) have a > >>>>>>>> problem > >>>>>>>> not loading mac_ntpd while others, i.e. my stable/14 at $JOB, are > >>>>>>>> fine. I'd > >>>>>>>> like to try to understand the differences between those that work an > d > >>>>>>>> those > >>>>>>>> that don't. > >>>>>>>> > >>>>>>>> First of all, the ntpd rc script bails without saying why when it > >>>>>>>> encounters a problem. can_run_nonroot() simply returns a bad return > co > >> de > >>>>>>>> leaving us to wonder why. > >>>>>>>> > >>>>>>>> The first order of business is to produce a patch to indicate why > it > >>>>>>>> bails. Please apply the attached patch and let me know where it fail > s. > >>>>>>>> Messages will be printed to stderr and to /var/log/messages (assumin > g > >>>>>>>> daemon.err is sent there). > >>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Tomoaki AOKI<junch...@dec.sakura.ne.jp> > >>>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> Cy Schubert<cy.schub...@cschubert.com> > >>>>>>>> FreeBSD UNIX:<c...@freebsd.org> Web:https://FreeBSD.org > >>>>>>>> NTP:<c...@nwtime.org> Web:https://nwtime.org > >>>>>>>> > >>>>>>>> e^(i*pi)+1=0 > >>>>>>> Output from the patch: > >>>>>>> > >>>>>>> Mar 11 17:20:35 plan-b ntpd[60113]: ntpd 4.2.8p18-a (17): Starting > >>>>>>> Mar 11 17:20:35 plan-b ntpd[60113]: Command line: /usr/sbin/ntpd -p > >>>>>>> /var/db/ntp/ntpd.pid -c /etc/ntp.conf -u ntpd:ntpd > >>>>>>> Mar 11 17:20:35 plan-b ntpd[60113]: > >>>>>>> ---------------------------------------------------- > >>>>>>> Mar 11 17:20:35 plan-b ntpd[60113]: ntp-4 is maintained by Network > >>>>>>> Time Foundation, > >>>>>>> Mar 11 17:20:35 plan-b ntpd[60113]: Inc. (NTF), a non-profit 501(c)(3 > ) > >>>>>>> public-benefit > >>>>>>> Mar 11 17:20:35 plan-b ntpd[60113]: corporation. Support and traini > ng > >>>>>>> for ntp-4 are > >>>>>>> Mar 11 17:20:35 plan-b ntpd[60113]: available at > >>>>>>> https://www.nwtime.org/support > >>>>>>> Mar 11 17:20:35 plan-b ntpd[60113]: > >>>>>>> ---------------------------------------------------- > >>>>>>> Mar 11 17:20:35 plan-b ntpd[60114]: switching logging to file > >>>>>>> /var/log/ntp > >>>>>>> Mar 11 17:20:36 plan-b ntpd[60113]: daemon child exited with code 255 > >>>>>>> Mar 11 17:20:36 plan-b root[60118]: /etc/rc.d/ntpd: WARNING: failed t > o > >>>>>>> start ntpd > >>>>>>> > >>>>>>> Debugging output from from the unpatched /etc/rc.d/ntpd: > >>>>>>> > >>>>>>> (...) > >>>>>>> > >>>>>>> + echo 'Starting ntpd.' > >>>>>>> Starting ntpd. > >>>>>>> + [ -n '' ] > >>>>>>> + _cd='' > >>>>>>> + _doit=' /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf > - > >> u > >>>>>>> ntpd:ntpd' > >>>>>>> + [ -n '' ] > >>>>>>> + [ -n '' ] > >>>>>>> + [ -n '' ] > >>>>>>> + [ -n '' ] > >>>>>>> + _doit=' limits -C daemon /usr/sbin/ntpd -p /var/db/ntp/ntpd.p > id > >>>>>>> -c /etc/ntp.conf -u ntpd:ntpd' > >>>>>>> + _run_rc_doit ' limits -C daemon /usr/sbin/ntpd -p > >>>>>>> /var/db/ntp/ntpd.pid -c /etc/ntp.conf -u ntpd:ntpd' > >>>>>>> + local _m > >>>>>>> + debug 'run_rc_command: doit: limits -C daemon /usr/sbin/ntpd > -p > >>>>>>> /var/db/ntp/ntpd.pid -c /etc/ntp.conf -u ntpd:ntpd' > >>>>>>> + umask > >>>>>>> + _m=0022 > >>>>>>> + > >>>>>>> + eval ' limits -C daemon /usr/sbin/ntpd -p /var/db/ntp/ntpd.pi > d > >> -c > >>>>>>> /etc/ntp.conf -u ntpd:ntpd' > >>>>>>> + limits -C daemon /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c > >>>>>>> /etc/ntp.conf -u ntpd:ntpd > >>>>>>> daemon control: got EOF > >>>>>>> + _return=255 > >>>>>>> + umask 0022 > >>>>>>> + [ 255 -ne 0 ] > >>>>>>> + [ -z '' ] > >>>>>>> + return 1 > >>>>>>> + warn 'failed to start ntpd' > >>>>>>> + [ -x /usr/bin/logger ] > >>>>>>> + logger '/etc/rc.d/ntpd: WARNING: failed to start ntpd' > >>>>>>> + echo '/etc/rc.d/ntpd: WARNING: failed to start ntpd' > >>>>>>> /etc/rc.d/ntpd: WARNING: failed to start ntpd > >>>>>>> + return 1 > >>>>>>> > >>>>>> The real problem is here: > >>>>>> + [ -n '' ] > >>>>>> + local 'fileopts=^[ \t]*crypto|^[ \t]*driftfile|^[ \t]*key|^[ > >>>>>> \t]*logfile|^[ \t]*statsdir' > >>>>>> + grep -E -q '^[ \t]*crypto|^[ \t]*driftfile|^[ \t]*key|^[ > >>>>>> \t]*logfile|^[ \t]*statsdir' /etc/ntp.conf > >>>>>> + return 1 > >>>>>> > >>>>>> To reproduce: use config matching the regex from the above, for exampl > e > >>>>>> add line: > >>>>>> > >>>>>> logfile /var/log/ntp.log > >>>>>> > >>>>>> to the ntp.conf > >>>>>> > >>>>>> 15-CURRENT is also affected this way. That's a bit odd that nobody > >>>>>> reported it yet. > >>>>>> > >>>>>> Problems made by can_run_nonroot function can be fixed by removing lin > es > >>>>>> 60-64 from the starting script. > >>>>>> > >>>>>> https://github.com/freebsd/freebsd-src/blob/main/libexec/rc/rc.d/ntpd# > L6 > >> 3 > >>>>> What is in your ntpd_config in rc.conf? > >>>> # grep ntpd_config /etc/rc.conf /etc/defaults/rc.conf > >>>> /etc/defaults/rc.conf:ntpd_config="/etc/ntp.conf" # ntpd(8) > >>>> configuration file > >>> Without the patch I replied with, we're back to guessing. Yet, every feel > s > >>> the problem is in a different part of the rc script. > >>> > >>> The mystery is why are all my instances (13, 14, 15) working and yours no > t? > >>> > >>> I have reverted the commit. A rewrite of the rc script will be required i > n > >>> order to implement ntpd's chroot. > >>> > >> I don't know. It's the same bug from the beginning, but it reveals in > >> different ways. It looks like the early exit from can_run_nonroot > >> function prevented loading mac_ntpd.ko module. All affected setups in my > >> case had set options: logfile, keys and driftfile what is probably still > >> completely fine. These configs are old, but the syntax is still correct > >> and I believe using ntp keys or setting logfile from the config directly > >> shouldn't be banished. > > Aside from my commit to use -u instead of su, the script hasn't changed, > > except for comments, since 2022. The problem must be your config, somewhere > . > > > > Reverting the script to rely in su instead of ntpd handling setuid() > > itself, though helping you now see that the commit wasn't the problem, was > > needless. Patching your script with the suggested error messaging patch > > would have given us clarity to the problem rather than randomly reverting > > commits until it magically worked. > > > > You need to apply the error messaging patch or we continue to *guess* what > > the problem might be. Guessing is not a smart debugging strategy. Sitting > > here at my desk I do not have any useful information beyond guesses. > > > > Sorry for the rant but I've worked on software support, sysadmin, and > > various development roles throughout my 50+ year career. When users provide > > little to no information to go on all we are left with is to guess. Right > > now my guess is that there is something wrong with your setup. Beyond that > > I don't know because the only information I have is, it doesn't work for > > you. And since I cannot reproduce your problem here on 15-CURRENT, > > 14.2-RELEASE, or 13.5-RELEASE, I have no additional visibility into your > > problem. > > > > I need data. > > > Dear Committer, > > in the past (and now, after the revert of commit > 521f66715afb312b356afafc68cbc044a436a753), NTPD was run as root. The > change introduced in 521f66715afb312b356afafc68cbc044a436a753 no longer > allowed root, but with mac_ntpd.ko loaded it was possible to start NTPD > using the ntpd user account. Removing line 63 from the startup scripts > [1], regardless of the change introduced by > 521f66715afb312b356afafc68cbc044a436a753, allows NTPD servers to be > started using the ntpd user account on all my affected machines. > Furthermore, all affected machines have "logfile", "keys" and > "driftfile" set, and NTPD works fine on them using the ntpd account if > only mac_ntpd is loaded. So indeed the topic "heads up: mac_ntpd has to > be explicitly loaded in recent stable/14" was unfortunate. Sorry for the > noise and bringing this up, because probably in the past on all these > machines NTPD was started using UID 0. Please allow me to apologize, I > simply missed a change made 7 years ago in the line 63 (grep -E -q > "${fileopts}" "${ntpd_config}" && return 1) and I was 100% sure that all > my servers use the mac_ntpd.ko policy and the NTPD daemon is started > under UID 123. Only few of them was behaving this way, the most of them > still used UID 0 to run the daemon. > > Dear Subscribers, > > please forgive me for making unnecessary noise again. > > I am so embarrassed that I will not write another post on this thread today. > > Yours sincerely > > 1.https://github.com/freebsd/freebsd-src/blob/main/libexec/rc/rc.d/ntpd#L63 > -- > Marek Zarychta >
The -u commit was the first step toward implementing ntpd chroot (--jaildir=). As we've seen the rc(8) plumbing is incompatible with this goal. The fact that it doesn't produce any error messages, silently failing makes it difficult to understand where the problem is. (We have this same issue at $JOB.) Using ntpd under root account is a security issue. It has had some RCE (remote code execution) vulnerabilities. Running it non-root somewhat mitigates this. The planned running it chrooted (--jaildir=) will protect users systems even more. Putting my security administrator hat on (a role I have at $JOB), users are advised to run ntpd non-root whenever possible. This is also the best advice for most other daemons as well, if one can do this. It limits the exposure should one be hit by a zero day RCE or an unpatched machine. It's recommended ntpd be run under the ntpd account. It's safer that way. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org NTP: <c...@nwtime.org> Web: https://nwtime.org e^(i*pi)+1=0
