carlos / platform Public

objstore: an app could mark its own object clean

Every verdict this platform reports rests on one asymmetry: the console
can write the carlos-scan tag and the app cannot. storePolicyJSON's
comment said so in capitals — "s3:PutObjectTagging is NOT, and MUST
NEVER BE ... that absence is the whole anti-forgery property" — and
AGENTS.md carries the same rule. The absence was real. It was also not
the whole property.

THERE ARE TWO WAYS TO PUT A TAG ON AN OBJECT. Leaving the permission out
of the Allow closes one: PutObjectTagging, the explicit call. The other
is the x-amz-tagging header on PutObject itself, which sets tags during
the upload and never names the tagging action at all. No search for an
action name can find it, which is exactly why three reviews and a
purpose-built helper missed it — assertNoPutObjectTagging grepped the
document for the string "s3:PutObjectTagging" and passed.

Against MinIO RELEASE.2025-09-07T16-13-09Z, stood up from CI's own
contract fixture and given today's policy verbatim, the upload succeeded
with carlos-scan=clean attached.

What that buys an attacker: the sweep reads the tag before scanning and
skips any object whose tagged version matches the current one
(clamav.go's Verdict). The version is etag@last-modified — the etag is
the app's own MD5 and the last-modified is the server clock at upload,
so an app can upload, HEAD its own object, and retry until the stamp it
guessed matches. The object is then never scanned, and `carlos store
scan scan status` reports it clean, permanently. The audit sentence the
whole feature exists to produce becomes a lie the platform tells
confidently.

THE OBVIOUS FIX DOES NOT WORK, which is the part worth remembering.
Adding an explicit Deny on s3:PutObjectTagging and s3:DeleteObjectTagging
was the first thing tried and the upload still succeeded: the gateway
never attributed the header to that action. Only denying s3:PutObject
itself, conditioned on the request carrying one of our tag keys
(ForAnyValue:StringEquals on s3:RequestObjectTagKeys), closed it. Both
Denys are here — the first costs nothing where the permission was
already absent, and it is the one AWS's own documentation says should
have sufficed.

Unconditional, not gated on enforcement. A store that is not enforcing
is exactly where a forged clean tag would sit unnoticed longest, and
these statements have nothing to do with whether infected objects are
readable.

The tests had encoded the old belief in five places — "two statements
when enforcement is off", `"Effect":"Deny"` used as a proxy for
"enforcement is on", and the grep helper. All five now say what they
meant. assertNoPutObjectTagging checks both routes and is called from
the AWS provisioner's assertion too, so a policy change cannot pass by
only satisfying one file.

TestDeliveredContractMinio gains the live half, against the real server
CI already runs on every push (.amadan/ci.d/30-minio-contract): the
tagging route in both forms, and — the other thing that could only be
settled against a real server — that HeadObject and ListObjectsV2 agree
on the version string. They do. The sweep binds its tag to the LIST
version and the status door heads the object to find its own, so a
gateway that reported those differently would make every sweep verdict
read as unknown and put the two paths into a rescan loop. That question
was going to be answered by deploying; it is answered by CI instead, on
every push rather than once.

Verified end to end: the policy the code generates, handed to MinIO
verbatim as the scoped user's policy, and the full contract test green
against it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PEkJh1ESqiA84quAHJV4K6