Bug 1672285

Summary: FreeRADIUS should not generate certificates at package installation
Product: Red Hat Enterprise Linux 8 Reporter: Stephen Gallagher <sgallagh>
Component: freeradiusAssignee: Alex Scheel <ascheel>
Status: CLOSED ERRATA QA Contact: Filip Dvorak <fdvorak>
Severity: medium Docs Contact: lmcgarry
Priority: unspecified    
Version: 8.0CC: ascheel, extras-qa, fdvorak, fhanzelk, lemenkov, lmcgarry, nikolai.kondrashov, pasik, rharwood, tscherf
Target Milestone: rc   
Target Release: 8.0   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: freeradius-3.0-8030020200806223029.1e4bbb35 Doc Type: Bug Fix
Doc Text:
.FreeRADIUS no longer generates certificates during package installation Previously, FreeRADIUS generated certificates during package installation, resulting in the following issues: * If FreeRADIUS was installed using Kickstart, certificates might be generated at a time when entropy on the system was insufficient, resulting in either a failed installation or a less secure certificate. * The package was difficult to build as part of an image, such as a container, because the package installation occurs on the builder machine instead of the target machine. All instances that are spawned from the image had the same certificate information. * It was difficult for an end-user to generate a simple VM in their environment as the certificates would have to be removed and regenerated manually. With this update, the FreeRADIUS installation no longer generates default self-signed CA certificates nor subordinate CA certificates. When FreeRADIUS is launched via `systemd`: * If all of the required certificates are missing, a set of default certificates are generated. * If one or more of the expected certificates are present, it does not generate new certificates.
 Story Points: ---
Clone Of: 1672284 Environment:
Last Closed: 2020-11-04 03:58:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1574783, 1672284, 1717880, 1720667    
Bug Blocks: 1842946    

Description Stephen Gallagher 2019-02-04 13:16:03 UTC 
+++ This bug was initially created as a clone of Bug #1672284 +++

Description of problem:
FreeRADIUS currently generates a self-signed CA certificate as well as subordinate certificates and some passwords while installing the freeradius package. This is against the Fedora Packaging Guidelines[1] for several good reasons:

1) If freeradius is installed via kickstart, the certificates may be generated at a time when entropy on the system is insufficient, resulting in either a failed installation (scriptlet returns non-zero) or a less-secure certificate.

2) The package cannot easily be built as part of an image (such as a container or ostree image) because the package installation occurs on the builder machine, not the target machine and thus all instances of it that are spawned from the image will have the same certificate information.

3) It makes it difficult for an end-user to generate a common VM in their environment. They can remove the certificates manually, but there's no simple way to regenerate them on the cloned children. The user must know how to do this themselves, manually.

Fedora packaging guidelines[1] now mandate that the behavior here should be that this certificate generation does not occur in an RPM scriptlet, but that it instead takes place as part of a systemd unit that is launched prior to (and blocks the start of) the main service unit for the package. Specific details on how to accomplish this are provided on the guidelines page. I am also available to help with the implementation if needed.

Moving the auto-generation from the scriptlet to the systemd unit addresses all three of the issues mentioned above.



Version-Release number of selected component (if applicable):

freeradius-3.0.17-4.fc30
freeradius-3.0-820190131191847.fbe42456


How reproducible:
Every time

Steps to Reproduce:
1. Install the `freeradius` package in Fedora/RHEL 8
2. Check the contents of /etc/raddb/certs


Actual results:
ca.pem, server.crt and many other certificates are present.

Expected results:
The certificates should not be present until the first time the service is launched.


Additional info:

[1] Fedora Packaging Guidelines:
https://fedoraproject.org/wiki/Packaging:Initial_Service_Setup
Comment 20 Alex Scheel 2020-07-22 11:13:20 UTC 
*** Bug 1857230 has been marked as a duplicate of this bug. ***
Comment 35 errata-xmlrpc 2020-11-04 03:58:12 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: freeradius:3.0 security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:4799
Comment 36 Alex Scheel 2020-11-23 13:23:30 UTC 
It came to my attention recently that some customers don't like this behavior.


To avoid this, use a systemd override file (execute `sudo systemctl edit radiusd.service` to create one) with the contents:

[Service]
ExecStartPre=
ExecStartPre=/usr/sbin/radiusd -C

to disable certificate generation at service startup.

This can be tested with `sudo systemctl restart radiusd.service`.

Please refer to the systemd docs for more information about unit file overrides.


I do not recommend editing the original systemd unit file we ship with FreeRADIUS RPM in RHEL as it is package configuration and subject to change in a future release.