「拒否したはずが通っていた」修正が、10日で4件並んだ

Claude Code の changelog に、拒否ルールが効いていなかったという修正が短期間に並んでいる。10月2日から6日の4日間で4件である。

版	日付	内容
2.1.292	10/06	PreToolUse フックの承認と auto mode が、ネットワーク（UNC）パスからのファイル読み取りで権限プロンプトを迂回していた
2.1.289	10/03	複合シェルコマンドの入れ子部分に対する deny / ask ルールが、管理対象マシン上でユーザーが入れた mod の承認を超えられなかった
2.1.289	10/03	`Read` の deny ルールが、シンボリックリンク経由で @メンション・変更・IDE で選択されたファイルに適用されていなかった
2.1.287	10/01	組織のツール単位の権限上限が、`__proto__` という名前の MCP ツールで黙って外れていた
2.1.288	10/02	サンドボックス内のコマンドが、`/ultrareview` のアップロードのステージされたファイルの写しを読めていた

形がどれも同じである

どれも「禁止したつもりが通っていた」であって、「禁止できなかった」ではない。

設定した側から見ると、ルールは書いてあり、画面上も有効になっている。エラーも警告も出ない。 実際に通っていることは、意図的に試さない限り分からない。

経路もそれぞれ別である。ネットワークパス、シンボリックリンク、シェルの入れ子、オブジェクトのプロパティ名。共通しているのは「同じファイルに別の名前で到達できる」という性質である。__proto__ はその JavaScript 版にあたる。

権限設計は、ルールを書いた時点では完成しない。

このサイトでは9月に --restricted を扱った。フラグで「できないこと」を固定できるのは良い設計だが、固定したものが本当に効いているかは別の話である。

実務で取れる手が3つある。

バージョンを上げる。 列挙した5件はいずれも修正済みである。設定が黙って外れる環境では、権限を絞った運用そのものが成立しない。 自動化やCIに組み込んでいるなら、更新の優先度は高い。

拒否ルールを、肯定的に検査する。 「禁止したから大丈夫」ではなく、禁止したものが実際に拒否されることを一度確かめる。 読めてはいけないファイルを読ませてみて、止まることを見る。1回やれば済む。

「同じものへの別の道」を疑う。 シンボリックリンク、ネットワークパス、相対パスの組み立て、エイリアス。ルールがパス文字列で書かれているなら、別の文字列で同じ場所に着けないかを考える。 これは Claude Code に限らず、アクセス制御全般の古い論点である。

9月の GTIG の報告でも、LLM ベースのスキャナに拒否を起こさせて検査を止める手口が挙がっていた。止まったことと、通ったことの区別が付かない設計は危うい。 今回の修正群は、その区別が付いていなかった例である。

記述はすべて Claude Code の changelog に記載されているものである。