Latest beta - chronyd / FIPS mode issue (resend to mail list)

[Vincent Moutoussamy]

Hi Kevin,

Thanks a lot for this details report, could you please create a bug report with all the information you already shared here? 
Then I’ll link your bug to "bsc#1173760 - FIPS: chrony aborts in FIPS mode due to MD5" and I’ll ask for setting a new priority to your bug. 

Thanks again and have a nice day,
Regards,
--
Vincent Moutoussamy
SUSE Beta Program Manager
JeOS Technical Project Manager
Paris, France

> On 5 Apr 2021, at 16:22, Kevin Salisbury <kevin.salisbury at twinmro.com> wrote:
> 
> Hi Malcolm,
> 
> It's been a while, trust all is well.
> 
> Yes unfortunately, everything works great until the system is placed into FIPS mode, then chronyd fails to run/start.
> 
> My team just found out (as I was typing this reply) that if we create a new SLE 15 chronyd local timesource server on the network and we point the SLE 15 FIPS/chronyd clients to the new local chronyd server, the client chronyd loads properly and runs! But we can't run the actual chronyd time server system in FIPS mode even with a public source - so it is still a problem but we can work with this (one system being out of compliance instead of all systems being out of compliance). This is our workaround at the moment. 
> 
> It seems SLES15 chronyd clients can not speak to SLES 12 ntp local time clocks if the SLE15 chronyd system/kernel is running in FIPS mode...
> 
> Kevin
> 
> 
> >>> On 4/5/2021 at 8:41 AM, <malcolmlewis at cableone.net> wrote:
> On Mon, 05 Apr 2021 07:51:31 -0400
> "Kevin Salisbury" <Kevin.Salisbury at twinmro.com> wrote:
> 
> > I have confirmation of a carryover chronyd bug from SP2 into SP3
> 
> > (bugzilla number 1173760).
> 
> >
> 
> > Steps to reproduce;
> 
> > - Built a new x86_64 SLES15 SP3 Beta box and updated.
> 
> > - Setup an internal time source for chronyd on install both manually
> 
> > and with autoyast - no issues. Time is fine.
> 
> > - Install FIPS pattern, and set grub bootloader kernel boot option
> 
> > 'fips=1' and restart
> 
> > - chronyd fails to load with internal time source. If a public time
> 
> > source is used for chronyd, it seems to load fine (but of course, one
> 
> > can't use a public source if servers are not supposed to see the
> 
> > internet or are "air gapped").
> 
> >
> 
> > We suspect there needs to be something else done on the internal time
> 
> > source, or a local configuration change not documented for FIPS
> 
> > systems; we've tried several different internal time clock sources
> 
> > and manual edits of chronyd configurations -- nothing seems to work.
> 
> > The issue does not exist on SLES 12 systems. Curious to know if
> 
> > others in FIPS environments have seen this behavior with SLE 15 and
> 
> > if there's a workaround...(it seems that we are missing something
> 
> > very simple, admittedly we are not experts with chronyd yet, but so
> 
> > far SUSE support can replicate the issue - but has no solution for us
> 
> > either).
> 
> >
> 
> > This post is FYI only. This is a known issue, although not documented
> 
> > in the readme, it's going to limit deployment in many regulated
> 
> > environments...
> 
> >
> 
> > Kevin
> 
> >
> 
> Hi
> Not a chrony expert or FIPS user either, but am using the aarch64 (RPi3)
> SLES 15 SP3 for a local time source with gps/pps/rtc which is working
> great.
> 
> Have you run makestep, is the time in use UTC, timedatectrl looks good,
> cmos battery ok, are the pools disabled (/etc/chrony.d/pool.conf?
> 
> Changed the stratum level?
> 
> --
> Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
> Tumbleweed 20210330 | GNOME Shell 3.38.3 | 5.11.6-1-default
> Intel DQ77MK  | Xeon E3-1245 V2 X8 @ 3.40 GHz | Intel/AMD/Nvidia
> up 9:20, 2 users, load average: 0.94, 1.12, 0.83