Bucket Policy on SILO

SN-2026-003: s3:versionid Condition Evaluation and Request Condition Hardening

Tue, 04 Aug 2026 00:00:00 +0000

SN-2026-003 and SN-2026-005 cover a set of S3 IAM policy evaluation fixes shipped in Server 20260804 (80c2c9d03, 2f55347f7, eee05a17c, and silo-pkg v3.12.0 commit 2b087a1; pgsty/silo#40, pgsty/silo#53):

SN-2026-003 (80c2c9d03): getConditionValues populated args.ConditionValues["versionid"] = []string{""} even when a request carried no versionId, causing IAM Null conditions on s3:versionid to evaluate as if the key were always present; fixing that alone would have opened a DeleteObjects XML <VersionId> bypass without per-entry rebinding in authorizeRequestWithTags.
Condition-source isolation (2f55347f7): Separated query parameters, HTTP headers, internal server keys, and s3:ExistingObjectTag/<key> vs. s3:RequestObjectTag/<key> so untrusted query strings or headers cannot spoof internal condition keys.
SN-2026-005 (2b087a1 / eee05a17c): Added ParseConfigStrict to reject degenerate bare resource prefixes ("arn:aws:s3:::" and "*arn:aws:s3:::") when writing IAM and bucket policies.

Conclusions first

Unconditional empty slice inverted Null checks: In silo-pkg, nullFunc.evaluate tests whether a condition key is absent by checking len(rvalues) == 0. Because getConditionValues unconditionally assigned args.ConditionValues["versionid"] = []string{vid} (producing []string{""} when vid == ""), len(rvalues) was always 1—making Null: {"s3:versionid": "true"} always false and Null: {"s3:versionid": "false"} always true.
Fixing getConditionValues alone breaks DeleteObjects: In multi-object DeleteObjects (POST /?delete), the target <VersionId> is inside each XML <Object> element, not in the URL query string. If getConditionValues simply omits "versionid" when the URL query has no versionId, a policy denying versioned deletes (Deny s3:DeleteObjectVersion or Condition: {"Null": {"s3:versionid": "false"}}) would fail to match DeleteObjects XML entries unless authorizeRequestWithTags rebinds ConditionValues["versionid"] from ReqInfo.VersionID.
Whitespace trimming closes a Deny bypass: Version-reading handlers called strings.TrimSpace(r.URL.Query().Get("versionId")), whereas getConditionValues did not trim whitespace. A request with ?versionId=V%20 bypassed Deny StringEquals {"s3:versionid": "V"} while still deleting or reading version V.

Why `Null` on `s3:versionid` Was Inverted

In silo-pkg/bucket/policy/condition/nullfunc.go, the IAM Null condition operator checks whether a condition key is missing from the request context:

SN-2026-004: Object-Scoped Policy Grants Reaching Bucket Mutations

Tue, 04 Aug 2026 00:00:00 +0000

SN-2026-004 fixes an IAM resource-matching flaw in silo-pkg v3.11.0 (3c24ad1, 1f97549, d8b1fa7) and Server 20260804 (97b7d2804; upstream reference minio/minio#20449): when evaluating bucket-level S3 requests (args.ObjectName == ""), Statement.IsAllowed synthesized "bucket/" as the target resource string, allowing object-scoped wildcard grants such as Allow s3:* on arn:aws:s3:::bucket/* to authorize sensitive bucket-level mutations including s3:PutBucketPolicy and s3:DeleteBucket.

Conclusions first

Root cause: When args.ObjectName was empty, Statement.IsAllowed appended '/' to the bucket name ("bucket/"), which matched the glob "arn:aws:s3:::bucket/*".
Privilege escalation: A tenant principal given Allow s3:* on arn:aws:s3:::tenant/* (a common shorthand for “all object operations inside this bucket”) could call PutBucketPolicy to grant Principal: "*" on the bucket, or call DeleteBucket, PutReplicationConfiguration, PutBucketLifecycle, PutBucketVersioning, or PutBucketObjectLockConfiguration.
Why a targeted fix was required: Simply dropping the trailing '/' for all empty-object checks broke 11 existing STS ListBucket tests and weakened Deny s3:* on arn:aws:s3:::bucket/* policies.
Targeted boundary: For the 12 sensitive bucket-mutation actions on Allow statements (!legacyBucketResourceMatch && statement.Effect == Allow && isSensitiveBucketMutation(args.Action)), the resource pattern must match both "bucket" and "bucket/". Setting MINIO_API_LEGACY_BUCKET_RESOURCE_MATCH=on restores pre-20260804 matching if a deployment temporarily relies on legacy policies.

Why `arn:aws:s3:::bucket/*` Matched Bucket Requests

In silo-pkg/bucket/policy/statement.go (and iam/policy/statement.go), Statement.IsAllowed(args Args) constructed the resource string to test against Statement.Resources as follows:

Bucket Policy on SILO

SN-2026-003: s3:versionid Condition Evaluation and Request Condition Hardening

Conclusions first

Why Null on s3:versionid Was Inverted

SN-2026-004: Object-Scoped Policy Grants Reaching Bucket Mutations

Conclusions first

Why arn:aws:s3:::bucket/* Matched Bucket Requests

Why `Null` on `s3:versionid` Was Inverted

Why `arn:aws:s3:::bucket/*` Matched Bucket Requests