サンドボックスポリシー

サンドボックスポリシー ペイン（セキュリティ グループの、ガードレールとサプライチェーンの間）は、マシンの VM がどこに届いてよいか、そして OpenShell エンジンでは、そのエージェントが VM の中で何をしてよいかを決めます（マシンは設定エディタでは「ワークスペース」です）。5.4 より前は ファイアウォール という名前でした。設定で firewall、openshell、sentry、landlock を検索すれば、今も見つかります。

ペインを開くと、まず Sandbox engine（サンドボックスエンジン）という一つの選択があります：

エンジンの仕組みと、Bromure のほかの保護との関係は、サンドボックスポリシー、ゲストサンドボックス、カーネル・セントリーで説明しています。このページは項目のリファレンスです。

OpenShell + Sentry に切り替えると、空のポリシーに組織の既定ポリシー（または Bromure のスターターポリシー）が入り、カーネル・セントリーが Best effort でオンになります。ポリシーがある状態で Bromure Firewall に戻そうとすると、まず Switch to the Bromure Firewall? と確認されます。Discard OpenShell policy はポリシーを削除し、カーネル・セントリーをオフにするからです（組織が必須にしている場合を除く）。ポリシーを残したいなら、先に 書き出す… を使ってください。

どちらのエンジンにも適用される保護 — ポリシーがブロックしたときのエージェントへの通知、エージェント・ウォッチドッグ、厳格な認証情報、透過的な傍受、安全でないバイパス — は、ガードレール › 保護機能にあります。

Bromure ファイアウォール

送信ルール

「VM の接続を、ホスト、IP/CIDR、プロトコル、ポートで許可または拒否します — 上から下へ照合し、最初に一致したものが決めます。」ルールはあらゆるプロトコルとあらゆる宛先に及びます。一致しない通信は、どのルールにも一致しない接続をどう扱うかを決めます：許可（既定）、または許可リスト方式にするなら拒否。ルールを追加で 1 行増えます。

「ルールは編集したそばから適用されます。キャンセルで元に戻ります。」再起動も保存も要りません：新しい接続はすぐに新しいルールに従い、すでに開いている接続も同様です。ルールをオフにする、削除する、拒否ルールを追加する、有効期間が切れる、停止までのルールが終わる — どれもマシンの開いている接続をすべて再確認し、新しいルールが拒否するものは両側で切断されます。一時的な許可をオフにすれば、開いたままのダウンロードを最後まで走らせることなく、アクセスが本当に終わります。

• プロキシ設定（HTTPS_PROXY — curl、git、npm、エージェントは既定でこれを使います）経由の接続は、プロキシ自身が切断します：VM 側を閉じ、サーバーへのリクエストを取り消します（WebSocket も含む）。セキュリティ タイムラインはそれぞれを 接続を切断 — 「allow tcp …」はもう許可していません として記録します。
• 直接接続は、仮想スイッチが次のパケットで切断します：そのパケットを捨てて VM に TCP リセットを送り、傍受された HTTP(S) 通信ではプロキシからサーバーへの接続も閉じます。

エディタを開いている間にエディタの外でルールが変わると（セキュリティ タイムラインの操作や、有効期間の終了など）、その変更は保存していない編集に統合されます。同じルールを編集していた場合は、ペインが 再読み込み か 編集内容を保持 かを尋ねます。

一時的なルール

ほんの一瞬だけ必要なルールもあります — たとえば依存関係を更新する間だけ GitHub や npm レジストリに届けばよい場合です。ルールを追加して削除を覚えておく代わりに、ルールの時計メニューで有効期間を設定します：

• 15 分間オン / 1 時間オン — 時間切れの瞬間に、Bromure が忙しくてもルールは一致しなくなります。その少し後にオフにされてそのまま保存されるので、次回のためにリストに残ります。
• ワークスペースが停止するまでオン — マシンが停止（または再起動）したときにルールはオフになります。アプリの終了時にまだ実行中だった場合は、次に Bromure を起動したときにオフになります。

後でもう一度使うには、チェックを入れるか、新しい有効期間を選びます。

いまブロックされたものを許可するいちばん速い方法は、マシンのウインドウにある Sandbox ドロワーか、セキュリティ タイムラインのブロックされた行の 許可… です。どちらも 常に、15 分間、1 時間、ワークスペースが停止するまで を選べます。

pf 形式

pf 形式の開閉部は、同じルールをテキストで示します — 1 行に 1 つ、末尾は default allow か default deny — これが保存される形であり、CLI と管理プロファイルが使う形です：

allow tcp api.github.com:443
allow web api.example.com GET,POST     # これらの動詞だけがサイトに届く
deny  web api.internal PUT,DELETE      # これらの動詞を遮り、残りは許可
deny  udp any:53
deny  any 10.0.0.0/8
default deny

オフにしたルールと一時的なルールにはコメントで短い注記が付くので、テキストは普通の pf のままです：

#@off allow tcp registry.npmjs.org:443          # オフ
allow tcp github.com:443 #@until=1767225600      # この時刻までオン（Unix 秒）
allow tcp pypi.org:443 #@until=stop              # マシンが停止するまでオン

実施は Mac 上で、2 つの層で行われます。仮想ネットワークスイッチが、宛先 IP と DNS で見たホスト名によってすべての接続を確かめ（全プロトコル）、プロキシが TLS のサーバー名で、web ルールについては HTTP メソッドでもう一度確かめます。だからこそ、マシンが書き込めない API を読むことができます：allow web api.example.com GET,POST は、エージェントがどのツールを使っていても、変更なしの問い合わせだけを与えます。

すべての判定は、それを決めたルールとともにセキュリティ タイムラインに記録され、登録済みの Mac では組織に送られます。

許可された接続の記録

ブロックされた接続は常に記録されます。一致しない通信の選択の下にある許可された接続を記録は、ファイアウォールが通した接続も記録するかどうかを決めます — これがあるから、その行に**ブロック…とルール…**のクイックアクションが付きます。選ぶまでは、マシンにルールがある（または一致しない通信を拒否する）ときはオン、ファイアウォールのないマシンではオフなので、ルールのないマシンがタイムラインを「許可」の行で埋めることはありません。

許可された接続はいずれにせよ控えめです：宛先（ホスト、ポート、プロトコル — 複数のアドレスの背後にあるホストも 1 行）ごとに最大で 1 分に 1 行で、繰り返しはカウント付きで前の行にまとめられます。Mac 上のローカルモデルのエンドポイントは一覧に出ません。

注： ローカルモデルには常に届きます。Mac 上の推論エンドポイントへの許可ルールがあなたのルールの前に置かれるので、default deny でもエージェントをオンデバイスのモデルから切り離すことはできません。

ファイアウォール下のカーネル・セントリー

カーネル・セントリーは OpenShell エンジンに属します。Bromure ファイアウォールのもとでまだセントリーを動かしているマシンには、Turn off 付きの Kernel sentry is still on カードが出ます。組織がセントリーを必須にしている場合は「Your organization requires at least …」と表示され、操作部はありません。

OpenShell + Sentry

エンジンの設定は 5 枚のカードに分かれています。

ポリシー

「ルールが許可しない限り、すべて拒否されます。即時に適用されます。」Policy カードにはポリシーそのもの、つまり YAML で書かれたスキーマバージョン 1 の NVIDIA OpenShell サンドボックスポリシーが入っています。接続を許可するのは network_policies のルールだけです。protocol を持つエンドポイントはリクエストごとに検査され、enforce ならブロック、audit なら記録だけを行います。変更は再起動なしで実行中のマシンに適用されます。

カードのボタン：

• インポート… — ポリシーを .yaml / .yml ファイルで置き換えます。
• 書き出す… — <machine>-policy.yaml として保存します。
• Reset to starter policy — スターターポリシーは GitHub（443 番の github.com、api.github.com、**.githubusercontent.com）、読み取り専用の npm と PyPI（検査あり、enforce）、そして 80/443 番の Ubuntu パッケージミラーを許可します。

エディタの下の確認行には、Valid policy · N network rules（緑）か解析エラー（赤）が表示され、警告があればその後に続きます。Enforce binaries がオンのときは、binaries を挙げていないルールがオレンジで示されます。そうしたルールは何も許可しません。

カーネル・セントリー

「セキュリティイベント（プロセスの起動、権限の変更、モジュールや BPF の読み込み、サンドボックスの拒否）を、エージェントが止められるものの外側で、VM のカーネルから Bromure へ送ります。起動後はカーネルがロックされ、VM の root でさえ干渉するコードを読み込めません。」ストリームの沈黙や欠落は、エージェント・ウォッチドッグにとって改ざんとみなされます。

Mode は次の VM 起動時に適用されます。組織が最低限を決めている場合は、二つのうち厳しいほうが適用され、最低限が Required なら Best effort はグレー表示になります（「Your organization requires it.」）。セントリーがエンジンに付属する前に設定されたマシンには、Turn on 付きで Off for this workspace と表示されます。

カードの状態行には、Connected · kernel バージョン または Not connected、負荷で失われたイベントがあればその数、VM がセントリーを読み込めなかったときは赤で Couldn't start: 理由 が表示されます。モジュールの届け方はカーネル・セントリーを参照してください。

サンドボックス

VM が問題を報告すると、カードの題名がオレンジの Sandbox ⚠︎ になります：ファイルシステムのサンドボックスや厳格なサンドボックスが適用されなかった、期待されているセントリーが使えない、またはゲストが警告を送ってきた、といった場合です。

Enforce binaries と Filesystem & process の下の状態行は、VM が実際に適用した内容を示します：

• Attestor connected: binaries are enforced、または Attestor not connected: until it is, only Bromure's own rules apply。
• Filesystem に続けて、その状態、エージェントがどのユーザーとして動くか、Landlock のバージョン。VM が報告する前は Filesystem not applied yet。
• Bromure が自分の配管のために追加するパス（Added for Bromure: …）。
• ファイルシステムは閉じ込められているがバイナリが強制されていないとき：「The agent keeps sudo, so it could stop Bromure's processes in the VM. Turn on Enforce binaries to prevent that.」
• 厳格なサンドボックスが適用されなかったときは赤で：「no session will start and binary rules fail closed. Restarting the VM retries it.」

ポリシーアドバイザー

リクエストがブロックされると、エージェントは必要な狭いルールを http://policy.local（OpenShell のアドバイザー API）に提案し、あなたの判断を待てます。ブロックされた接続も、ここで提案として下書きされます。

保留中の提案には、ルールと宛先、それが drafted from a block（ブロックから下書き）か proposed by the agent（エージェントの提案）か、エージェントが述べた意図、YAML、そしてリスクの指摘があればオレンジで表示されます。必要なら Reason (sent to the agent on reject) を入力し、Reject か Approve を押します。承認されたルールはポリシーに追加され、即時に適用されます。Recent decisions には直近の 5 件が並びます。同じ提案は Sandbox ドロワーにも表示されます。

ガバナンス

• Organization boundary — どのマシンのポリシーでも許可できる上限です。Set by your organization (bromure.io)、Set on this Mac（Set from file… と クリア 付き）、または None set. のいずれかです。ポリシーを変える保存はすべてこれと照合されます。NVIDIA の openshell-prover がインストールされていればそれで、なければ Bromure 組み込みのチェックで行います。境界を超えるポリシーは、どこで編集されたか（ペイン、Sandbox ドロワー、アドバイザー、API）にかかわらず、境界の要約とともに拒否されます。
• Revision history — ポリシーを変える保存はそれぞれバージョンとして残ります（vN、日付、変更の出どころ、短いハッシュ付き）。復元 はあるバージョンをエディタに読み戻します。
• Rules Bromure adds automatically — OpenShell のプロバイダールールと同じく、マシンのエージェントと、マシンが設定するすべての認証情報が届くようにします。書き出したポリシーには含まれません。

ブロックされたときエージェントが見るもの

ポリシーが拒否した接続は、ソケットがぶら下がることなく、すぐに失敗します。OpenShell ポリシーのもとでは、拒否されたプロキシ経由の接続や検査対象のリクエストは、OpenShell 独自の policy_denied 本文付きの HTTP 403 を受け取ります：層、ホストとポート（またはメソッドとパス）、そしてルールか理由です。ポリシーアドバイザーがオンなら、本文は http://policy.local でルールを提案する方法もエージェントに伝えます。Tell the agent when policy blocks it がオンなら（ガードレールを参照）、エージェントは会話の中でも、何を試みたか、ポリシーがそれを禁じていること、回り道をせずあなたに尋ねるべきことを伝えられます。

設定リファレンス

ルールの表とポリシーエディタは iPhone・iPad・Vision Pro のクライアントには出ません（「Outbound connection rules are edited on the Mac that runs this workspace.」）。Mac で設定したルールとポリシーはそのまま効きます。

関連する章

• サンドボックスポリシー、ゲストサンドボックス、カーネル・セントリー — エンジンの仕組み。
• ガードレール — 認証情報のポリシーと、両エンジンに共通する保護機能。
• 認証情報 — OpenShell のプロバイダープロファイルと認証情報のプレースホルダー。
• セキュリティ概要とタイムライン — マシンごとの、すべての遮断と許可、そしてネットワーク・リネージ。