第656回ではChromeベースのEPUBリーダーをsnapパッケージ化してみました。今回はsnapパッケージ作成における最大のハードルと言える「strict confinement」の対応を行いましょう。ここまで対応できれば，「⁠snapパッケージ完全に理解した」と言えますし，Snap Storeにも公開できるようになります（※1⁠）⁠。

※1

ここの「完全に理解した」は，あとで理解していないことに気づくほうの「完全に理解した」フェーズです。

snapパッケージにおけるセキュリティモデル

snapパッケージではアプリケーションを「コンテナ化」することで，ホストシステムから隔離した環境で実行できる仕組みを構築しています。その「コンテナ化」を実現するために，次のような機能を利用しています。

• 古くから存在するディレクトリのパーミッションなどの任意アクセス制御（DAC：Discretionary Access Controls）
• AppArmorを活用した強制アクセス制御（MAC：Mandatory Access Control）
• seccompを利用したシステムコールの利用制限
• cgroupを利用したハードウェアリソースへのアクセス制御

つまりいわゆる「コンテナ管理システム」のようなことを実現しているわけです。これにより個々のsnapパッケージは，簡単にはホストシステムを参照できず，ユーザーはパッケージごとにどのリソースにアクセスするかを柔軟に設定できます。

どれくらい隔離するかは，パッケージ側でもビルド時に設定可能です。それがsnapcraft.yamlに記述する「confinement（封じ込め）」キーワードです。snapパッケージでは次の3つから選択できます。

devmode

パッケージの開発時にのみ利用する，まったく隔離せずアクセスログのみを残すモード

strict

システムからは完全に隔離された状態で，アクセスが必要な場合は個別に許可しなければならないモード

classic

従来のdebパッケージのように，システムへのアクセスを許容するモード

このうちclassicは特殊なモードです。作ろうとしているsnapパッケージが，たとえばホストシステム上のホームディレクトリーや（/mediaにマウントされた）外部ストレージ以外にアクセスしなければならないケース，snapが実装しているリソース管理ではカバーしきれないケースなどに利用されます。classicなsnapパッケージは，snapによる隔離環境の外に存在することになるため，パッケージを公開するためには十分な理由とストアの管理者によるレビュー対応を求められます。

つまりsnapパッケージを作るなら，基本的にdevmodeで作って，その後strictに対応するのが一般的な流れです。

strictなパッケージが，たとえばインターネットに通信したい場合，そのsnapパッケージに「ネットワーク接続への許可」を与える必要があります。このような個別のリソースへのアクセス権限を，snapでは「interface（インターフェース）」と呼んでいます。

ネットワーク接続したいならnetworkインターフェース，カメラデバイスにアクセスしたいならcameraインターフェース，ホームディレクトリにアクセスしたいならhomeインターフェースなどなど，多種多様なインターフェースが存在します。

インターフェースは「Plug（プラグ⁠）⁠」と「Slot（スロット⁠）⁠」に分割されます。プラグはsnapパッケージ側からのリソースアクセス要求であり，スロットはその要求を受けるsnapシステム側のインターフェースです（※2⁠）⁠。プラグをスロットに接続することではじめてコネクションが確立し，snapパッケージはリソースを利用できるようになります。

※2

snapパッケージ側が，他のsnapパッケージ向けにSlotを用意するケースも存在します。

言い換えるとsnapシステムに存在しないスロットに対するプラグは作れません。もしスロットが存在しないリソースを使いたいなら，新規にスロットの作成を提案するか，classicパッケージとして作るかの二択になります。

「strictに対応する」ということは，そのsnapパッケージが必要とするリソースを洗い出し，実装済みのインターフェースの中から使用するスロットをリストアップする作業なのです。