QA (public) » openQA Project (public) » openQA Tests (public)

sample long running openssl users:

apache2
openssh (daemon)
postfix

you would need to inject the LD_PRELOAD=libpulp.so howevert in their systemd config scripts via:

[Service]
Environment="LD_PRELOAD=libpulp.so.0"

Sample manual testprocedure:

• install all updates
• configure apache2 for SSL support
• configure apache2 for livepatch support, add in the [Service] section:

Environment="LD_PRELOAD=libpulp.so.0"

• start apache2 and verify SSL access works.
• verify libpulp.so is loaded in httpd using "lsof" lsof |grep http.*pulp
  

Then we need to test all variants that get livepatched:

LOOP over all released openssl-1_1 versions (GA, 1st Update, 2nd Update, ... last update)

• install the selected libopenssl1_1 version
• restart apache2 to use this version
• test https access to the apache2 server
• apply the openssl-livepatches RPM. it SHOULD report something like:

ulp: patches reverse-all failed in libpulp.so: Target library not loaded
httpd-prefork (pid: 22685): SUCCESS /usr/lib64/openssl-1_1-livepatches/0.1/libcrypto_1.1.1l-150400.7.10.5_livepatch1.so
ulp: patches reverse-all failed in libpulp.so: Target library not loaded
httpd-prefork (pid: 22691): SUCCESS /usr/lib64/openssl-1_1-livepatches/0.1/libcrypto_1.1.1l-150400.7.10.5_livepatch1.so
ulp: patches reverse-all failed in libpulp.so: Target library not loaded
httpd-prefork (pid: 22692): SUCCESS /usr/lib64/openssl-1_1-livepatches/0.1/libcrypto_1.1.1l-150400.7.10.5_livepatch1.so
ulp: patches reverse-all failed in libpulp.so: Target library not loaded
httpd-prefork (pid: 22693): SUCCESS /usr/lib64/openssl-1_1-livepatches/0.1/libcrypto_1.1.1l-150400.7.10.5_livepatch1.so
ulp: patches reverse-all failed in libpulp.so: Target library not loaded
httpd-prefork (pid: 22694): SUCCESS /usr/lib64/openssl-1_1-livepatches/0.1/libcrypto_1.1.1l-150400.7.10.5_livepatch1.so
ulp: patches reverse-all failed in libpulp.so: Target library not loaded
httpd-prefork (pid: 22695): SUCCESS /usr/lib64/openssl-1_1-livepatches/0.1/libcrypto_1.1.1l-150400.7.10.5_livepatch1.so
ulp: Processes patched: 0, Skipped: 6, Failed: 0.
(output is weird ... not sure if this is 100% ok)

• test https access to the apache2 server again , if not FAIL
• test if lp is really loaded ( it loads the shared module from the package), if not FAIL lsof |grep http.*livepatches httpd-pre 22685 root mem REG 253,2 6760 242393 /usr/lib64/openssl-1_1-livepatches/0.1/libcrypto_1.1.1l-150400.7.10.5_livepatch1.so

My understanding is that in future qam-kernel/qam-sle groups are not to be assigned for such updates

The more I look at this task, the more it feels that it is a qe-security task, cc @tjyrinki_suse

From the former QE Security we inherited certain specific security related features (STIG, SCAP, apparmor, TPM, ...), and testing libraries like openssl under FIPS.I'd like to keep the current status quo even though it's all lines in sand, mostly because there starts to be more and more security focus in ALP and I'd like to try distinct between security-by-default features (security for everyone) and more special security features.

For example for Full Disk Encryption we discussed at one point that QE Core or YaM would test the default FDE, and we would test the TPM part.

For this specific case, it's security all over but it's also a general feature like live patching combined with one of the most common libraries around, so all in all it's not very special.

For openssl we concentrate on fixed openssl versions that do not usually see updates, even live updates.

Does this make sense?

See also updated testing https://qam.suse.de/reports/SUSE:Maintenance:31520:313169/log due to some packaging changes (livepatches now pull in fixed version of library so that manual downgrade to vulnerable version is necessary)

We had received the 2nd wave of openssl-*-livepatches, this time for both 15-SP4 and 15-SP5 (S:M:31520:313169 + S:M:31521:313460). To meet the deadlines, tests had to be executed manually.

As the number of products supporting these kind of updates is going to grow steady, please reconsider raising the priority of this task and make it part of the next sprints.