From 53ff5e703e1552aeb2f492347d9af5742dd9ad4c Mon Sep 17 00:00:00 2001 From: Daniel Beck Date: Fri, 8 Mar 2024 09:32:15 +0100 Subject: [PATCH] Change label to 'Jenkins user database' --- content/_data/changelogs/weekly.yml | 2 +- content/doc/book/security/access-control.adoc | 2 +- content/doc/book/security/managing-security.adoc | 4 ++-- .../admin-password-reset-instructions.adoc | 2 +- content/security/advisory/2014-02-14.adoc | 2 +- content/security/advisory/2015-02-27.adoc | 2 +- content/security/advisory/2015-10-01.adoc | 4 ++-- content/security/advisory/2018-10-10.adoc | 4 ++-- 8 files changed, 11 insertions(+), 11 deletions(-) diff --git a/content/_data/changelogs/weekly.yml b/content/_data/changelogs/weekly.yml index 6e1c3235e0ea..2629655276a4 100644 --- a/content/_data/changelogs/weekly.yml +++ b/content/_data/changelogs/weekly.yml @@ -21705,7 +21705,7 @@ - url: https://github.com/jenkinsci/jep/blob/master/jep/237/README.adoc title: JEP-237 message: |- - Developer: Optionally support a FIPS140 compliant algorithm in the Jenkins' own user database. + Developer: Optionally support a FIPS140 compliant algorithm in the Jenkins user database. # pull: 8546 (PR title: Bump commons-io:commons-io from 2.13.0 to 2.14.0) # pull: 8554 (PR title: Actually adjust copy button logic to new API) diff --git a/content/doc/book/security/access-control.adoc b/content/doc/book/security/access-control.adoc index 3c982407560f..92a572d04f03 100644 --- a/content/doc/book/security/access-control.adoc +++ b/content/doc/book/security/access-control.adoc @@ -44,7 +44,7 @@ Using the *logged-in users can do anything* authorization strategy can be a sens This is the default with Jenkins's single admin user when setting up Jenkins with the setup wizard. + Switching to an authentication realm that allows untrusted users to have an account later will result in those users getting administrative access to Jenkins if you keep this authorization strategy. -Examples include enabling account signup for _Jenkins' own user database_, or various other authorization realms, many of which (GitHub, Google, GitLab, etc.) allow anyone to sign up for an account. +Examples include enabling account signup for _Jenkins user database_, or various other authorization realms, many of which (GitHub, Google, GitLab, etc.) allow anyone to sign up for an account. Anonymous and authenticated users:: Similar to the previous items, you should generally not grant significant permissions to `anonymous` (the anonymous user) or authenticated (any authenticated user) when using an authorization strategy that allows finer-grained control (like plugin:matrix-auth[Matrix Authorization Strategy]). diff --git a/content/doc/book/security/managing-security.adoc b/content/doc/book/security/managing-security.adoc index 311129db5a26..c984c0b07b3d 100644 --- a/content/doc/book/security/managing-security.adoc +++ b/content/doc/book/security/managing-security.adoc @@ -39,7 +39,7 @@ some of them. == Enabling Security Beginning with Jenkins 2.214 and Jenkins LTS 2.222.1, the "Enable Security" checkbox has been removed. -Jenkins own user database is used as the default security realm. +Jenkins user database is used as the default security realm. In versions before Jenkins 2.214 and Jenkins LTS 2.222.1, when the *Enable Security* checkbox is checked, users can log in with a username and password in order to @@ -104,7 +104,7 @@ Delegate to servlet container:: For delegating authentication a servlet container running the Jenkins controller, such as link:https://www.eclipse.org/jetty/[Jetty]. If using this option, please consult the servlet container's authentication documentation. -Jenkins’ own user database:: Use Jenkins's own built-in user data store for +Jenkins user database:: Use Jenkins's own built-in user data store for authentication instead of delegating to an external system. This is enabled by default with new Jenkins 2.0 or later installations and is suitable for smaller environments. diff --git a/content/doc/book/system-administration/admin-password-reset-instructions.adoc b/content/doc/book/system-administration/admin-password-reset-instructions.adoc index d68b77b6ce9e..2b26042a2b80 100644 --- a/content/doc/book/system-administration/admin-password-reset-instructions.adoc +++ b/content/doc/book/system-administration/admin-password-reset-instructions.adoc @@ -30,7 +30,7 @@ You may use this command: `systemctl start jenkins`. After restarting Jenkins, navigate to your controller and sign in. 7. On the dashboard, select *Manage Jenkins* in the navigation pane on the left side of the page. 8. On the *Manage Jenkins* page, under the *Security* section, select *Configure Global Security*. -9. Under *Security Realm*, select *Jenkins' own user database* from the dropdown menu. +9. Under *Security Realm*, select *Jenkins user database* from the dropdown menu. Ensure the option *Allow users to sign up* is unchecked and save your changes. This redirects you to the Manage Jenkins page. 10. On the **Manage Jenkins** page, select **Users**. diff --git a/content/security/advisory/2014-02-14.adoc b/content/security/advisory/2014-02-14.adoc index ff7645e77587..7b39f3278c19 100644 --- a/content/security/advisory/2014-02-14.adoc +++ b/content/security/advisory/2014-02-14.adoc @@ -33,7 +33,7 @@ Deleting the user was not invalidating the API token, allowing users to access J Jenkins UI was vulnerable to click jacking attacks. === SECURITY-79 -"Jenkins' own user database" was revealing the presence/absence of users when login attempts fail. +"Jenkins user database" was revealing the presence/absence of users when login attempts fail. === SECURITY-77 Jenkins had a cross-site scripting vulnerability in one of its cookies. If Jenkins is deployed in an environment that allows an attacker to override Jenkins cookies in victim's browser, this vulnerability can be exploited. diff --git a/content/security/advisory/2015-02-27.adoc b/content/security/advisory/2015-02-27.adoc index 085261722256..5d5d05473a19 100644 --- a/content/security/advisory/2015-02-27.adoc +++ b/content/security/advisory/2015-02-27.adoc @@ -25,7 +25,7 @@ This vulnerability allows authenticated users to disrupt the operation of Jenkin This vulnerability allows users with the read access to Jenkins to retrieve arbitrary XML document on the server, resulting in the exposure of sensitive information inside/outside Jenkins. === SECURITY-166 (HudsonPrivateSecurityRealm allows creation of reserved names) -For users using "Jenkins' own user database" setting, Jenkins doesn't refuse reserved names, thus allowing privilege escalation. +For users using "Jenkins user database" setting, Jenkins doesn't refuse reserved names, thus allowing privilege escalation. === SECURITY-167 (External entity processing in XML can reveal sensitive local files) This vulnerability allows attackers to create malicious XML documents and feed that into Jenkins, which causes Jenkins to retrieve arbitrary XML document on the server, resulting in the exposure of sensitive information inside/outside Jenkins. diff --git a/content/security/advisory/2015-10-01.adoc b/content/security/advisory/2015-10-01.adoc index 2346e1b57fd4..826507fd093c 100644 --- a/content/security/advisory/2015-10-01.adoc +++ b/content/security/advisory/2015-10-01.adoc @@ -36,5 +36,5 @@ If you're running a Jenkins instance on a public network, link:https://wiki.jenk It is important that it is _not_ possible for anonymous users to perform administrative actions or run scripts. This means: * Do *not* use the _Anyone can do anything_ authorization strategy. -* Do *not* use the _Logged-in users can do anything_ authorization strategy while allowing users to sign up when using _Jenkins’ own user database_. -* Do *not* give significant permissions (beyond read access) to the _authenticated_ group when using a more complex authorization strategy such as _Matrix-based security_ while allowing users to sign up when using _Jenkins’ own user database_. \ No newline at end of file +* Do *not* use the _Logged-in users can do anything_ authorization strategy while allowing users to sign up when using _Jenkins user database_. +* Do *not* give significant permissions (beyond read access) to the _authenticated_ group when using a more complex authorization strategy such as _Matrix-based security_ while allowing users to sign up when using _Jenkins user database_. \ No newline at end of file diff --git a/content/security/advisory/2018-10-10.adoc b/content/security/advisory/2018-10-10.adoc index 92fcab087ca4..501a3c9cbe24 100644 --- a/content/security/advisory/2018-10-10.adoc +++ b/content/security/advisory/2018-10-10.adoc @@ -74,7 +74,7 @@ issues: severity: medium vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L description: | - By accessing a specific crafted URL on Jenkins instances using _Jenkins' own user database_, users without Overall/Read access could create ephemeral user records. + By accessing a specific crafted URL on Jenkins instances using _Jenkins user database_, users without Overall/Read access could create ephemeral user records. This behavior could be abused to create a large number of ephemeral user records in memory. @@ -88,7 +88,7 @@ issues: severity: medium vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N description: | - When signing up for a new user account on instances using _Jenkins' own user database_, Jenkins did not invalidate the existing session and create a new one. + When signing up for a new user account on instances using _Jenkins user database_, Jenkins did not invalidate the existing session and create a new one. This allowed session fixation. Jenkins now invalidates the existing session and creates a new one when logging in after user signup.