mirror of
https://github.com/rustfs/rustfs.git
synced 2026-08-10 07:06:53 +00:00
Zhengchao An
b2a376c2d2
* fix(admin): bound IAM import archive expansion MAX_IAM_IMPORT_SIZE caps the compressed upload at 10 MB, but every member of the archive was then read with read_to_end into an unbounded Vec. Deflate ratios well above 100:1 are easy to construct, so a small authorized upload could expand without limit across the seven members ImportIam reads. Add a shared expansion budget (MAX_IAM_IMPORT_EXPANDED_SIZE, 10x the compressed cap) drawn down by every member, and route all seven reads through one helper that reads a byte past the remaining budget to detect overrun. Sharing the budget bounds the archive as a whole rather than letting each member spend the full limit independently. Covers R03-CAN-024 through R03-CAN-030 plus R04-CAN-077 (backlog #1471) — one fix rather than seven, since all seven call sites were byte-identical. * fix(kms): confine local key paths and refuse silent key replacement Local KMS key identifiers arrive from request input — the `name` tag on CreateKey, the `keyId` body field or query parameter on DeleteKey — and were joined onto `key_dir` with no validation. An identifier such as `../../tmp/evil` escaped the configured directory, making key creation a constrained arbitrary-file write and `DeleteKey` with `force_immediate` a cross-directory delete. Validate in `master_key_path` and make it fallible, so every filesystem path in this backend inherits the guard: decode_stored_key, load_master_key, save_master_key, create_key and delete_key all derive their paths there. The rule is containment rather than a character allowlist, so identifiers already in use keep resolving; only separators, NUL, absolute paths and non-single-component forms are refused. Note `.` and `..` are contained rather than refused — the `.key` suffix turns them into the ordinary filenames `..key` and `...key`. Separately, `LocalKmsBackend::create_key` had no existence check, while the sibling `KmsClient::create_key` has always had one. Since `save_master_key` renames over its destination, creating a key under an existing name silently replaced its material and destroyed the ability to decrypt everything wrapped under it — and the backend path is the one the admin API uses. It now returns KeyAlreadyExists, matching StaticKmsBackend. Covers R03-CAN-072, R03-CAN-073 and R07-CAN-103 (backlog #1475). R03-CAN-073 needed no separate change: delete_key routes both its load and its remove_file through master_key_path. * fix(swift): bound SLO manifest reads to the 2 MiB manifest limit The three Swift SLO handlers that load a stored manifest (handle_slo_get, handle_slo_get_manifest, handle_slo_delete) read the `<object>.slo-manifest` object to EOF with AsyncReadExt::read_to_end. That key is predictable and writable through the ordinary object PUT path, so a tenant can replace the manifest with an arbitrarily large object and then make the server allocate its full size on every SLO GET, multipart-manifest=get, or multipart-manifest=delete request - a memory amplification bounded only by the stored object size (CWE-400 / CWE-770). The 2 MiB manifest limit that handle_slo_put enforces was not applied on the read side. Introduce MAX_SLO_MANIFEST_SIZE (the existing 2 MiB PUT limit, now a named constant) and a shared read_manifest_bytes helper that reads through a `take(limit + 1)` and rejects anything larger, so an oversized manifest is refused instead of being buffered first. All three call sites go through the helper. handle_slo_put now checks the size before parsing the JSON. Regression tests: test_read_manifest_bytes_rejects_oversized_manifest and test_read_manifest_bytes_stops_reading_oversized_manifest (which asserts the reader is not consumed past the limit), plus a boundary test that a manifest at exactly 2 MiB is still accepted. * fix(protocols): authorize every object in FTPS/WebDAV recursive deletes The FTPS and WebDAV gateways authorized only the container before a recursive delete and then destroyed everything inside it without a further check: - FTPS RMD (and DELE on a bucket path ending in '/') cleared s3:DeleteBucket, then delete_bucket_recursively listed the bucket and deleted every object. - WebDAV DELETE on a bucket did the same via its own delete_bucket_recursively. - WebDAV DELETE on a directory cleared s3:DeleteObject for the directory marker key ("dir/") only, then listed that prefix and deleted every child under it. A principal holding s3:DeleteBucket (or s3:DeleteObject on a single marker key) could therefore erase objects it had no s3:DeleteObject permission for, and the operation reported success. Deletion stays recursive - that is the expected behaviour for these protocols - but each object now clears s3:DeleteObject on its own key before it is removed, and the enumeration clears s3:ListBucket. A denial aborts the whole operation with access denied rather than being skipped, so the caller can never be told the delete succeeded while objects were left behind or removed without authorization. The test double gained shared-state cloning, delete_object/delete_bucket call logs, and list/delete queue helpers so the regression tests can observe that nothing is deleted once a deny lands. * fix(server,ecstore): bound TLS handshakes and remote volume RPC waits Three call sites let an unauthenticated client or a misbehaving peer hold server resources with no deadline. TLS listener (R03-CAN-035): process_connection awaited `acceptor.accept(socket)` with no bound. A client that opens a TCP connection and never finishes the handshake parks a Tokio task and a socket forever, and the connection cap (RUSTFS_API_MAX_CONNECTIONS) is unlimited by default, so nothing else sheds it. The handshake now runs under accept_tls_with_deadline(), reusing the existing HTTP/1 header-read budget — the established slow-client bound for the pre-request phase — and the expiry is recorded through the same log/metric path as a handshake error, under a new TIMEOUT failure kind. Remote disk RPCs (R03-CAN-049, R03-CAN-050): list_volumes and delete_volume passed Duration::ZERO, which execute_with_timeout treats as "no deadline", so a peer that accepts the request and never answers stalls the coordinator (and, for delete_volume, the bucket-deletion workflow). Both now pass get_max_timeout_duration(), matching every sibling method in the file. Regression tests: a silent TLS peer must be shed by the handshake deadline; list_volumes/delete_volume against a peer that completes the TCP connect and then goes silent must fail with DiskError::Timeout instead of hanging. * fix(security): stop leaking signed headers and bound OIDC/KMS credentials Three independent hygiene fixes found by the security review. R03-CAN-018 (crates/signer): try_get_canonical_headers and get_signed_headers logged the complete header map at DEBUG before signing. Runtime callers pass session credentials and SSE-C key material through these headers, so anyone able to raise the log level (or read DEBUG logs) recovered X-Amz-Security-Token and SSE-C keys verbatim. The statements were debugging leftovers with no operational value and are deleted rather than redacted. R03-CAN-014 (crates/iam): the OIDC HTTP adapter buffered provider responses with an unbounded Response::bytes(), so a configured, compromised or attacker-pointed IdP endpoint could stream an arbitrarily large or endless body into memory (the ValidateOidcConfig admin handler lets a ServerInfo caller choose the endpoint). Responses are now read incrementally and fail closed past MAX_OIDC_RESPONSE_SIZE, and the already SSRF-hardened client builder gains request and connect timeouts so a stalled provider cannot pin the calling task indefinitely. R07-CAN-105 (helm): the Vault KMS token was serialized into the chart ConfigMap, exposing it to every subject allowed to get ConfigMaps in the namespace. It now renders into a dedicated Secret that the Deployment and StatefulSet consume via envFrom; the Secret is separate from the main credentials Secret so it also works when secret.existingSecret is set. Regression tests: - rustfs-signer: signing_never_logs_signed_header_material - rustfs-iam: oidc_response_body_past_the_limit_is_rejected, oidc_response_body_at_the_limit_is_accepted - scripts/test_helm_templates.sh: KMS token must never render in plaintext * fix(webdav): enforce body limit, request timeout and connection cap The configured WebDAV maximum body size was enforced from Content-Length, so a chunked request declared no length and bypassed it entirely. The configured request timeout was never applied to the connection at all, and the accept loop spawned a task per connection with no bound, so an unauthenticated client could hold resources indefinitely and in unbounded number. Enforce the limit on bytes actually read rather than the declared length, apply the configured timeout to the request, and bound accepted connections with a new RUSTFS_WEBDAV_MAX_CONNECTIONS (default 1024) surfaced in the config report. Covers R03-CAN-051, R03-CAN-052, R03-CAN-067, R04-CAN-089, R05-CAN-094 and R05-CAN-097 (backlog #1471, #1474). * fix(security): stop STS credentials from crossing the parent trust boundary Two related credential-boundary holes let a short-lived STS credential act with the full, unrestricted authority of the long-term user it was minted from. AddUser (R03-CAN-021, CWE-269/863): should_check_deny_only relaxes the admin policy check to deny-only when a Console/STS session targets the IAM user it represents. Nothing then stopped that session from calling AddUser with its own parent's access key, so the handler wrote an attacker-chosen secret key and status over the parent's stored Credentials via create_user -> save_user_identity. A session that expires in minutes became permanent control of the account. AddUser now rejects any temp or service-account requester whose resolved parent equals the target access key, resolving the parent the same way should_check_deny_only does (parent_user field, else the JWT `parent` claim, since some stores persist the parent only in the token). FTPS/SFTP/WebDAV password auth (R04-CAN-086, CWE-287/862): these protocols looked the access key up with check_key, which falls back to the STS account cache, and then compared only the stored secret. An STS access key plus secret therefore authenticated with no session token presented and no session-policy claims applied - the holder got the parent's full permissions. Password authentication now rejects temporary credentials before the secret comparison. The discriminator is is_temp() && !is_service_account(), the same one IamCache::update_user_with_claims uses to route an identity into the STS cache, so service accounts - which resolve policy from stored IAM state rather than a client-presented token - keep working over these protocols. Regression tests cover both predicates and pin the guards to their call sites so neither can be dropped without a test failure.
190 lines
9.3 KiB
Rust
190 lines
9.3 KiB
Rust
// Copyright 2024 RustFS Team
|
|
//
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
// you may not use this file except in compliance with the License.
|
|
// You may obtain a copy of the License at
|
|
//
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
//
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
// See the License for the specific language governing permissions and
|
|
// limitations under the License.
|
|
|
|
/// TLS related environment variable names and default values
|
|
/// Environment variable to enable TLS key logging
|
|
/// When set to "1", RustFS will log TLS keys to the specified file for debugging purposes.
|
|
/// By default, this is disabled.
|
|
/// To enable, set the environment variable RUSTFS_TLS_KEYLOG=1
|
|
pub const ENV_TLS_KEYLOG: &str = "RUSTFS_TLS_KEYLOG";
|
|
|
|
/// Default value for TLS key logging
|
|
/// By default, RustFS does not log TLS keys.
|
|
/// To change this behavior, set the environment variable RUSTFS_TLS_KEYLOG=1
|
|
pub const DEFAULT_TLS_KEYLOG: bool = false;
|
|
|
|
/// Environment variable to trust system CA certificates
|
|
/// When set to "1", RustFS will trust system CA certificates in addition to any
|
|
/// custom CA certificates provided in the configuration.
|
|
/// By default, this is disabled.
|
|
/// To enable, set the environment variable RUSTFS_TRUST_SYSTEM_CA=1
|
|
pub const ENV_TRUST_SYSTEM_CA: &str = "RUSTFS_TRUST_SYSTEM_CA";
|
|
|
|
/// Default value for trusting system CA certificates
|
|
/// By default, RustFS does not trust system CA certificates.
|
|
/// To change this behavior, set the environment variable RUSTFS_TRUST_SYSTEM_CA=1
|
|
pub const DEFAULT_TRUST_SYSTEM_CA: bool = false;
|
|
|
|
/// Environment variable to trust leaf certificates as CA
|
|
/// When set to "1", RustFS will treat leaf certificates as CA certificates for trust validation.
|
|
/// By default, this is disabled.
|
|
/// To enable, set the environment variable RUSTFS_TRUST_LEAF_CERT_AS_CA=1
|
|
pub const ENV_TRUST_LEAF_CERT_AS_CA: &str = "RUSTFS_TRUST_LEAF_CERT_AS_CA";
|
|
|
|
/// Default value for trusting leaf certificates as CA
|
|
/// By default, RustFS does not trust leaf certificates as CA.
|
|
/// To change this behavior, set the environment variable RUSTFS_TRUST_LEAF_CERT_AS_CA=1
|
|
pub const DEFAULT_TRUST_LEAF_CERT_AS_CA: bool = false;
|
|
|
|
/// Default filename for client CA certificate
|
|
/// client_ca.crt (CA bundle for verifying client certificates in server mTLS)
|
|
pub const RUSTFS_CLIENT_CA_CERT_FILENAME: &str = "client_ca.crt";
|
|
|
|
/// Environment variable for client certificate file path
|
|
/// RUSTFS_MTLS_CLIENT_CERT
|
|
/// Specifies the file path to the client certificate used for mTLS authentication.
|
|
/// If not set, RustFS will look for the default filename "client_cert.pem" in the current directory.
|
|
/// To set, use the environment variable RUSTFS_MTLS_CLIENT_CERT=/path/to/client_cert.pem
|
|
pub const ENV_MTLS_CLIENT_CERT: &str = "RUSTFS_MTLS_CLIENT_CERT";
|
|
|
|
/// Default filename for client certificate
|
|
/// client_cert.pem
|
|
pub const RUSTFS_CLIENT_CERT_FILENAME: &str = "client_cert.pem";
|
|
|
|
/// Environment variable for client private key file path
|
|
/// RUSTFS_MTLS_CLIENT_KEY
|
|
/// Specifies the file path to the client private key used for mTLS authentication.
|
|
/// If not set, RustFS will look for the default filename "client_key.pem" in the current directory.
|
|
/// To set, use the environment variable RUSTFS_MTLS_CLIENT_KEY=/path/to/client_key.pem
|
|
pub const ENV_MTLS_CLIENT_KEY: &str = "RUSTFS_MTLS_CLIENT_KEY";
|
|
|
|
/// Default filename for client private key
|
|
/// client_key.pem
|
|
pub const RUSTFS_CLIENT_KEY_FILENAME: &str = "client_key.pem";
|
|
|
|
/// RUSTFS_SERVER_MTLS_ENABLE
|
|
/// Environment variable to enable server mTLS
|
|
/// When set to "1", RustFS server will require client certificates for authentication.
|
|
/// By default, this is disabled.
|
|
/// To enable, set the environment variable RUSTFS_SERVER_MTLS_ENABLE=1
|
|
pub const ENV_SERVER_MTLS_ENABLE: &str = "RUSTFS_SERVER_MTLS_ENABLE";
|
|
|
|
/// Default value for enabling server mTLS
|
|
/// By default, RustFS server mTLS is disabled.
|
|
/// To change this behavior, set the environment variable RUSTFS_SERVER_MTLS_ENABLE=1
|
|
pub const DEFAULT_SERVER_MTLS_ENABLE: bool = false;
|
|
|
|
// ── HTTP Transport Tuning Parameters ──
|
|
|
|
/// Environment variable for HTTP/2 initial stream window size (bytes)
|
|
/// Default: 4194304 (4 MB)
|
|
pub const ENV_H2_INITIAL_STREAM_WINDOW_SIZE: &str = "RUSTFS_H2_INITIAL_STREAM_WINDOW_SIZE";
|
|
pub const DEFAULT_H2_INITIAL_STREAM_WINDOW_SIZE: u32 = 4 * 1024 * 1024; // 4 MB
|
|
|
|
/// Environment variable for HTTP/2 initial connection window size (bytes)
|
|
/// Default: 8388608 (8 MB)
|
|
pub const ENV_H2_INITIAL_CONN_WINDOW_SIZE: &str = "RUSTFS_H2_INITIAL_CONN_WINDOW_SIZE";
|
|
pub const DEFAULT_H2_INITIAL_CONN_WINDOW_SIZE: u32 = 8 * 1024 * 1024; // 8 MB
|
|
|
|
/// Environment variable for HTTP/2 max frame size (bytes)
|
|
/// Range: 16384 (16 KB) to 16777216 (16 MB) per RFC 7540
|
|
/// Default: 524288 (512 KB)
|
|
pub const ENV_H2_MAX_FRAME_SIZE: &str = "RUSTFS_H2_MAX_FRAME_SIZE";
|
|
pub const DEFAULT_H2_MAX_FRAME_SIZE: u32 = 512 * 1024; // 512 KB
|
|
|
|
/// Environment variable for HTTP/2 max header list size (bytes)
|
|
/// Default: 65536 (64 KB)
|
|
pub const ENV_H2_MAX_HEADER_LIST_SIZE: &str = "RUSTFS_H2_MAX_HEADER_LIST_SIZE";
|
|
pub const DEFAULT_H2_MAX_HEADER_LIST_SIZE: u32 = 64 * 1024; // 64 KB
|
|
|
|
/// Environment variable for HTTP/2 max concurrent streams
|
|
/// Default: 2048
|
|
pub const ENV_H2_MAX_CONCURRENT_STREAMS: &str = "RUSTFS_H2_MAX_CONCURRENT_STREAMS";
|
|
pub const DEFAULT_H2_MAX_CONCURRENT_STREAMS: u32 = 2048;
|
|
|
|
/// Environment variable for HTTP/2 keep-alive interval (seconds)
|
|
/// Default: 20
|
|
pub const ENV_H2_KEEP_ALIVE_INTERVAL: &str = "RUSTFS_H2_KEEP_ALIVE_INTERVAL";
|
|
pub const DEFAULT_H2_KEEP_ALIVE_INTERVAL: u64 = 20;
|
|
|
|
/// Environment variable for HTTP/2 keep-alive timeout (seconds)
|
|
/// Default: 10
|
|
pub const ENV_H2_KEEP_ALIVE_TIMEOUT: &str = "RUSTFS_H2_KEEP_ALIVE_TIMEOUT";
|
|
pub const DEFAULT_H2_KEEP_ALIVE_TIMEOUT: u64 = 10;
|
|
|
|
/// Environment variable for HTTP/1.1 header read timeout (seconds)
|
|
/// Default: 75
|
|
///
|
|
/// In hyper's HTTP/1.1 stack this timeout is armed as soon as the connection is
|
|
/// ready to read the *next* request head, so on a keep-alive connection it also
|
|
/// bounds how long an idle upstream connection is allowed to sit before RustFS
|
|
/// closes it. Reverse proxies (Caddy, Nginx) pool upstream connections and keep
|
|
/// them idle far longer than a few seconds (Caddy ≈ 2 min, Nginx = 60 s by
|
|
/// default). A short value here makes RustFS FIN pooled connections while the
|
|
/// proxy still believes they are alive; the proxy then reuses a dead socket and
|
|
/// the client sees `socket hang up` / connection reset — most visibly on
|
|
/// non-idempotent `PUT` uploads, which proxies will not transparently retry
|
|
/// (see issue #3076).
|
|
///
|
|
/// The default is therefore set above common proxy idle-keepalive windows.
|
|
/// Operators fronting RustFS with a proxy should keep this larger than the
|
|
/// proxy's upstream idle-keepalive, or lower the proxy's keepalive below this
|
|
/// value. Environments that expose RustFS directly to untrusted slow clients and
|
|
/// want tighter slowloris protection can lower it via the env var below.
|
|
///
|
|
/// The same budget bounds the TLS handshake on the listener, so an unauthenticated
|
|
/// peer cannot park an accept task and its socket indefinitely by opening a
|
|
/// connection and then stalling the handshake.
|
|
pub const ENV_HTTP1_HEADER_READ_TIMEOUT: &str = "RUSTFS_HTTP1_HEADER_READ_TIMEOUT";
|
|
pub const DEFAULT_HTTP1_HEADER_READ_TIMEOUT: u64 = 75;
|
|
|
|
/// Environment variable for HTTP/1.1 max buffer size (bytes)
|
|
/// Default: 65536 (64 KB)
|
|
pub const ENV_HTTP1_MAX_BUF_SIZE: &str = "RUSTFS_HTTP1_MAX_BUF_SIZE";
|
|
pub const DEFAULT_HTTP1_MAX_BUF_SIZE: usize = 64 * 1024; // 64 KB
|
|
|
|
/// Environment variable for the S3 request-body inter-chunk read timeout
|
|
/// (seconds). Default: 300. Set to 0 to disable.
|
|
///
|
|
/// This bounds how long a `PutObject`/upload may wait for the *next* body chunk
|
|
/// while more bytes are still expected. It resets on every chunk, so it does not
|
|
/// penalize slow-but-progressing uploads — it only fires when a peer sends a
|
|
/// partial body and then goes silent *without* closing the connection (no EOF).
|
|
/// A reverse proxy or CDN that forwards a truncated body this way would
|
|
/// otherwise make RustFS wait forever for bytes that never arrive; with this
|
|
/// timeout the stalled read is aborted and logged with the received/expected
|
|
/// byte counts, turning a silent hang into an actionable diagnostic (issue
|
|
/// #3076). A short-body that arrives with a proper EOF is already rejected
|
|
/// promptly and is unaffected by this setting.
|
|
pub const ENV_HTTP_REQUEST_BODY_READ_TIMEOUT: &str = "RUSTFS_HTTP_REQUEST_BODY_READ_TIMEOUT";
|
|
pub const DEFAULT_HTTP_REQUEST_BODY_READ_TIMEOUT: u64 = 300;
|
|
|
|
// ── TLS Hot Reload Parameters ──
|
|
|
|
/// Environment variable to enable TLS certificate hot reload
|
|
/// Default: false
|
|
/// To enable, set the environment variable RUSTFS_TLS_RELOAD_ENABLE=1
|
|
pub const ENV_TLS_RELOAD_ENABLE: &str = "RUSTFS_TLS_RELOAD_ENABLE";
|
|
|
|
/// Default value for TLS certificate hot reload
|
|
/// By default, RustFS does not reload TLS certificates automatically.
|
|
pub const DEFAULT_TLS_RELOAD_ENABLE: bool = false;
|
|
|
|
/// Environment variable for TLS certificate reload interval (seconds)
|
|
/// Default: 30 seconds. Minimum: 5 seconds.
|
|
pub const ENV_TLS_RELOAD_INTERVAL: &str = "RUSTFS_TLS_RELOAD_INTERVAL";
|
|
|
|
/// Default interval for TLS certificate reload check
|
|
pub const DEFAULT_TLS_RELOAD_INTERVAL: u64 = 30;
|