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

Kevin Salisbury Kevin.Salisbury at twinmro.com
Mon Apr 5 14:22:55 UTC 2021


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.suse.com/pipermail/sle-beta/attachments/20210405/a602d868/attachment-0001.htm>


More information about the sle-beta mailing list