diff options
Diffstat (limited to 'doc/security')
| -rw-r--r-- | doc/security/crime_vulnerability.md | 4 | ||||
| -rw-r--r-- | doc/security/index.md | 6 | ||||
| -rw-r--r-- | doc/security/information_exclusivity.md | 4 | ||||
| -rw-r--r-- | doc/security/reset_user_password.md | 10 | ||||
| -rw-r--r-- | doc/security/two_factor_authentication.md | 15 | ||||
| -rw-r--r-- | doc/security/user_file_uploads.md | 48 | ||||
| -rw-r--r-- | doc/security/webhooks.md | 2 |
7 files changed, 63 insertions, 26 deletions
diff --git a/doc/security/crime_vulnerability.md b/doc/security/crime_vulnerability.md index 7956e692887..5a6578f218b 100644 --- a/doc/security/crime_vulnerability.md +++ b/doc/security/crime_vulnerability.md @@ -32,7 +32,7 @@ Although SPDY is enabled in Omnibus installations, CRIME relies on compression ## Nessus -The Nessus scanner, [reports a possible CRIME vulnerability](https://www.tenable.com/plugins/index.php?view=single&id=62565) in GitLab +The Nessus scanner, [reports a possible CRIME vulnerability](https://www.tenable.com/plugins/nessus/62565) in GitLab similar to the following format: ```plaintext @@ -59,7 +59,7 @@ vulnerability. ## References - NGINX ["Module `ngx_http_spdy_module`"](https://nginx.org/en/docs/http/ngx_http_spdy_module.html) -- Tenable Network Security, Inc. ["Transport Layer Security (TLS) Protocol CRIME Vulnerability"](https://www.tenable.com/plugins/index.php?view=single&id=62565) +- Tenable Network Security, Inc. ["Transport Layer Security (TLS) Protocol CRIME Vulnerability"](https://www.tenable.com/plugins/nessus/62565) - Wikipedia contributors, ["CRIME"](https://en.wikipedia.org/wiki/CRIME) Wikipedia, The Free Encyclopedia <!-- ## Troubleshooting diff --git a/doc/security/index.md b/doc/security/index.md index 73ac5028db5..9e05621333b 100644 --- a/doc/security/index.md +++ b/doc/security/index.md @@ -28,8 +28,6 @@ type: index - [Project Import decompressed archive size limits](project_import_decompressed_archive_size_limits.md) - [Responding to security incidents](responding_to_security_incidents.md) -## Securing your GitLab installation +To harden your GitLab instance and minimize the risk of unwanted user account creation, consider access control features like [Sign up restrictions](../user/admin_area/settings/sign_up_restrictions.md) and [Authentication options](../topics/authentication/index.md) . -Consider access control features like [Sign up restrictions](../user/admin_area/settings/sign_up_restrictions.md) and [Authentication options](../topics/authentication/) to harden your GitLab instance and minimize the risk of unwanted user account creation. - -Self-hosting GitLab customers and administrators are responsible for the security of their underlying hosts, and for keeping GitLab itself up to date. It is important to [regularly patch GitLab](../policy/maintenance.md), patch your operating system and its software, and harden your hosts in accordance with vendor guidance. +Self-managed GitLab customers and administrators are responsible for the security of their underlying hosts, and for keeping GitLab itself up to date. It is important to [regularly patch GitLab](../policy/maintenance.md), patch your operating system and its software, and harden your hosts in accordance with vendor guidance. diff --git a/doc/security/information_exclusivity.md b/doc/security/information_exclusivity.md index 0d55881c147..754d5fff843 100644 --- a/doc/security/information_exclusivity.md +++ b/doc/security/information_exclusivity.md @@ -24,8 +24,8 @@ limitation. You can take steps to prevent unintentional sharing and information destruction. This limitation is the reason why only certain people are allowed to [add users to a project](../user/project/members/index.md) -and why only a GitLab administrator can [force push a protected -branch](../user/project/protected_branches.md). +and why only a GitLab administrator can +[force push a protected branch](../user/project/protected_branches.md). <!-- ## Troubleshooting diff --git a/doc/security/reset_user_password.md b/doc/security/reset_user_password.md index 06934b187c1..992a8585a47 100644 --- a/doc/security/reset_user_password.md +++ b/doc/security/reset_user_password.md @@ -81,7 +81,15 @@ If you know the username, user ID, or email address, you can use the Rails conso new_password = ::User.random_password user.password = new_password user.password_confirmation = new_password - ``` + ``` + + To set a specific value for the new password: + + ```ruby + new_password = 'examplepassword' + user.password = new_password + user.password_confirmation = new_password + ``` 1. Optional. Notify the user that an administrator changed their password: diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md index 5907860f5cc..93d77a69f0e 100644 --- a/doc/security/two_factor_authentication.md +++ b/doc/security/two_factor_authentication.md @@ -71,7 +71,7 @@ The following are important notes about 2FA: 2FA for the project. For example, if project *P* belongs to 2FA-enabled group *A* and is shared with 2FA-disabled group *B*, members of group *B* can access project *P* without 2FA. To ensure this scenario doesn't occur, - [prevent sharing of projects](../user/group/index.md#prevent-a-project-from-being-shared-with-groups) + [prevent sharing of projects](../user/group/access_and_permissions.md#prevent-a-project-from-being-shared-with-groups) for the 2FA-enabled group. - If you add additional members to a project within a group or subgroup that has 2FA enabled, 2FA is **not** required for those individually added members. @@ -129,6 +129,7 @@ sudo -u git -H bundle exec rake gitlab:two_factor:disable_for_all_users RAILS_EN > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/270554) in GitLab 13.7. > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/299088) from GitLab Free to GitLab Premium in 13.9. > - It's deployed behind a feature flag, disabled by default. +> - Push notification support [introduced](https://gitlab.com/gitlab-org/gitlab-shell/-/issues/506) in GitLab 15.3. FLAG: On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../administration/feature_flags.md) named `two_factor_for_cli`. On GitLab.com, this feature is not available. The feature is not ready for production use. This feature flag also affects [session duration for Git Operations when 2FA is enabled](../user/admin_area/settings/account_and_limit_settings.md#customize-session-duration-for-git-operations-when-2fa-is-enabled). @@ -136,14 +137,20 @@ On self-managed GitLab, by default this feature is not available. To make it ava Two-factor authentication can be enforced for Git over SSH operations. However, we recommend using [ED25519_SK](../user/ssh.md#ed25519_sk-ssh-keys) or [ECDSA_SK](../user/ssh.md#ecdsa_sk-ssh-keys) SSH keys instead. -The one-time password (OTP) verification can be done using a command: +To perform one-time password (OTP) verification, run: ```shell ssh git@<hostname> 2fa_verify ``` -After the OTP is verified, Git over SSH operations can be used for a session duration of -15 minutes (default) with the associated SSH key. +Then authenticate by either: + +- Entering the correct OTP. +- In GitLab 15.3 and later, responding to a device push notification if + [FortiAuthenticator is enabled](../user/profile/account/two_factor_authentication.md#enable-one-time-password-using-fortiauthenticator). + +After successful authentication, you can perform Git over SSH operations for 15 minutes (default) with the associated +SSH key. ### Security limitation diff --git a/doc/security/user_file_uploads.md b/doc/security/user_file_uploads.md index dcdd18a9f0b..7c11d01396d 100644 --- a/doc/security/user_file_uploads.md +++ b/doc/security/user_file_uploads.md @@ -5,21 +5,45 @@ group: Authentication and Authorization info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments --- -# User File Uploads **(FREE)** +# User file uploads **(FREE)** -Images that are attached to issues, merge requests, or comments -do not require authentication to be viewed if they are accessed directly by URL. -This direct URL contains a random 32-character ID that prevents unauthorized -people from guessing the URL for an image, thus there is some protection if an -image contains sensitive information. +> - Enforced authorization checks [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80117) in GitLab 14.8 [with a flag](../administration/feature_flags.md) named `enforce_auth_checks_on_uploads`. Disabled by default. +> - Enforced authorization checks became [generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/352291) in GitLab 15.3. Feature flag `enforce_auth_checks_on_uploads` removed. +> - Project settings in the user interface [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/88567) in GitLab 15.3. -Authentication is not enabled because images must be visible in the body of -notification emails, which are often read from email clients that are not -authenticated with GitLab, such as Outlook, Apple Mail, or the Mail app on your -mobile device. +In private or internal projects, GitLab restricts access to uploaded files (such as PDFs) +to authenticated users only. By default, image files are not subject to the same +restriction, and unauthenticated users can use the URL to view the +file. If you enable authorization checks for all media files, images +receive the same protection and are viewable only by authenticated users. -NOTE: -Non-image attachments do require authentication to be viewed. +Users can upload files to issues, merge requests, or comments in a project. Direct URLs +to these images in GitLab contain a random 32-character ID to help prevent +unauthorized users from guessing image URLs. This randomization provides some protection +if an image contains sensitive information. + +Authentication checks for images can cause display issues in the body of notification emails. +Emails are frequently read from clients (such as Outlook, Apple Mail, or your mobile device) +not authenticated with GitLab. Images in emails appear broken and unavailable if +the client is not authorized to GitLab. + +## Enable authorization checks for all media files + +Non-image attachments (including PDFs) always require authentication to be viewed. +You can use this setting to extend this protection to image files. + +Prerequisite: + +- You must have the Maintainer or Owner role for the project. +- Your project visibility settings must be **Private** or **Internal**. + +To configure authentication settings for all media files: + +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **Settings > General**. +1. Expand **Visibility, project features, permissions**. +1. Scroll to **Project visibility** and select **Require authentication to view media files**. + You cannot select this option for projects with **Public** visibility. <!-- ## Troubleshooting diff --git a/doc/security/webhooks.md b/doc/security/webhooks.md index c3d445103c4..f2066ee4a42 100644 --- a/doc/security/webhooks.md +++ b/doc/security/webhooks.md @@ -74,7 +74,7 @@ allowlist: The allowed entries can be separated by semicolons, commas or whitespaces (including newlines) and be in different formats like hostnames, IP addresses and/or IP ranges. IPv6 is supported. Hostnames that contain Unicode characters should -use [Internationalized Domain Names in Applications](https://www.icann.org/resources/pages/glossary-2014-02-04-en#i) +use [Internationalized Domain Names in Applications](https://www.icann.org/en/icann-acronyms-and-terms/internationalized-domain-names-in-applications-en) (IDNA) encoding. The allowlist can hold a maximum of 1000 entries. Each entry can be a maximum of |