| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| dont-install-deleted-files.diff | no | |||||
| fix-include-paths.diff | fix include paths for debian & ubuntu | Timo Aaltonen <tjaalton@ubuntu.com> | no | |||
| debian-support.diff | changes for Debian * fix various hardcoded values to match debian & ubuntu * replace /etc/sysconfig/ with /etc/dogtag or /etc/default, where appropriate * fix selinux policy |
Timo Aaltonen <tjaalton@ubuntu.com> | no | |||
| fix-symkey-path.diff | fix the libsymkey.so JNI install path | Timo Aaltonen <tjaalton@ubuntu.com> | no | |||
| fix-format-security-warnings.patch | Fix GCC -Wformat-security warnings | Benjamin Drung <benjamin.drung@profitbricks.com> | no | |||
| use-root-homedir.diff | no | |||||
| use-bash.diff | no | |||||
| create-target-wants.diff | no | |||||
| fix-tomcat-paths.diff | no | |||||
| fix-tomcat-jars.diff | no | |||||
| fix-hamcrest-jar.diff | no | |||||
| fix-healthcheck-install.diff | no | |||||
| fix-runuser-path.diff | diff --git a/base/server/python/pki/server/__init__.py b/base/server/python/pki/server/__init__.py index 13550358e..cc4a2c6f2 100644 |
no | ||||
| CVE-2021-20179.diff | [PATCH] Fix renewal profile approval process Due to a recent change in PKI CLI, the CLI now passes along user authentication with submissions to the renewal endpoint. Unlike the EE pages, the REST API has passed along this authentication for a while. Due to a bug in the RenewalProcessor, requests with credentials against profiles with no authentication method and no ACLs result in the certificiate automatically being approved. This occurs because, when an earlier commit (cb9eb967b5e24f5fde8bbf8ae87aa615b7033db7) modified the code to allow Light-Weight SubCAs to issue certificates, validation wasn't done on the passed principal, to see if it was a trusted agent. Because profiles requring Agent approval have an empty ACL list (as, no user should be able to submit a certificate request and have it automatically signed without agent approval), authorize allows any user to approve this request and thus accepts the AuthToken. Critical analysis: the RenewalProcessor code interprets (authToken != null) as evidence that the authenticated user is /authorized/ to immediately issue the certificate. This mismatch of concerns (authn vs authz) resulted in a misunderstanding of system behaviour. The "latent" AuthToken (from the HTTP request) was assigned to authToken without realising that authorization needed to be performed. We fix this by splitting the logic on whether the profile defines an authenticator. If so, we (re)authenticate and authorize the user according to the profile configuration. If the profile does not define an authenticator but there is a principal in the HTTP request, if (and only if) the user has permission to approve certificate requests *and* the requested renewal profile is caManualRenewal (which is hardcoded to be used for LWCA renewal), then we issue the certificate immediately. This special case ensures that LWCA renewal keeps working. Otherwise, if there is no principal in the HTTP request or the principal does not have permission to approve certificate requests, we leave the authToken unset. The resulting renewal request will be created with status PENDING, i.e. enqueued for agent review. |
Fraser Tweedale <ftweedal@redhat.com> | no | 2021-01-13 |