Ubuntu VMで学ぶ「強制アクセス制御：MAC」

AppArmorで「そのユーザーなら読める」を「そのプロセスには読ませない」に変える

Linux の権限管理に少し慣れてくると、こんな場面にぶつかります。

「ファイル権限としては読めてしまう。だが、そのアプリケーションには読ませたくない。」

この時点で、chmod や ACL だけでは少し苦しくなります。なぜなら、それらは基本的に「ユーザーやグループに対する権限設定」だからです。一方、実際に縛りたい対象はユーザーそのものではなく、その権限で動くプロセスであることが多いからです。

ここで必要になるのが強制アクセス制御（MAC: Mandatory Access Control）です。Ubuntu では、この MAC を担う代表的な仕組みが AppArmor です。

この記事では、Ubuntu VM を使って AppArmor を触りながら、DAC では足りない部分をどう補うのかを具体的に見ていきます。

AppArmor は“プログラム単位の制限”

AppArmor の見方は難しくありません。一言で言えば、実行ファイルごとに許可された操作を定義する仕組みです。

つまり、

• どのファイルを読めるか

• どのパスに書けるか

• どの機能を使えるか

• どのネットワーク操作を許すか

これらを、アプリケーション単位で縛ります。

ここが DAC と違うところです。DAC は「alice に読み取り権があるか」を見ます。AppArmor は「/usr/bin/whatever にそのファイルを読ませてよいか」を見ます。

まずは状態確認

Ubuntu では AppArmor が既に入っていることが多いですが、操作用ツールも入れておくと楽です。

sudo apt updatesudo apt install -y apparmor apparmor-utils

状態を確認します。

sudo aa-status

ここで、ロード済みプロファイルや enforce / complain の状態が見えます。

enforce と complain の違いを先に理解する

AppArmor を触るときに最初に理解しておきたいのは、次の2つです。

• enforce: 違反を実際に拒否する

• complain: 違反を記録するが拒否はしない

この違いを曖昧にしたまま触ると、何が起きているのか分からなくなります。

最初の検証では complain で挙動を見て、影響が分かってから enforce に上げる、という流れが扱いやすいです。

既存プロファイルを触って感覚をつかむ

いきなりゼロから作るより、まずは既存プロファイルを見た方が早いです。

ls /etc/apparmor.d

プロファイルファイルが並んでいるはずです。ここで対象の実行ファイルに対応するものを探します。状態切り替えの例はこんな形です。

sudo aa-complain /usr/bin/mansudo aa-enforce /usr/bin/man

これで対象プロファイルを complain または enforce に切り替えられます。

独自プロファイルを作るなら aa-genprof が入口

自作スクリプトや独自デーモンを縛りたい場合は、aa-genprof を使うと入りやすいです。

たとえば /usr/local/bin/sampleapp を対象にするなら次です。

sudo aa-genprof /usr/local/bin/sampleapp

その後、対象アプリを実際に動かしてログを発生させ、必要な許可だけを取り込んでいく流れになります。

この手順を踏むと、AppArmor を“設定ファイルを手書きする重い仕組み”ではなく、実際の挙動から必要権限を絞り込む仕組みとして理解しやすくなります。

典型的な使いどころは“ラテラルムーブメント抑制”

AppArmor は、平常時より侵害発生時に真価を発揮します。

たとえば Web アプリが侵害されたとします。そのプロセスが動作ユーザーとして読める範囲が広いと、被害範囲も広がります。一方、AppArmor で読めるパスや書ける場所を最小限にしておけば、侵害後の活動をかなり狭められます。

つまり AppArmor は、「何が動くか」より「侵害された後にどこまで動けるか」を削る仕組みとして効きます。ここを意識すると、導入の意味がかなり明確になります。

MACの難しさ

ただし、MAC は DAC より明らかに重いです。必要なアクセスを洗い出さずにいきなり厳しくしすぎると、普通にアプリが動かなくなります。

AppArmor でも、この問題を緩和するために complain モードと enforce モードがあります。complain は違反を許可しつつ記録し、enforce は実際に拒否します。Ubuntu の公式文書でも、aa-complain と aa-enforce が共通コマンドとして示されています。

つまり MAC は、強い代わりに、設計と観察を雑にできません。何を読ませる必要があるのか、どこへ書く必要があるのか、プロファイルの粒度をきちんと見なければいけません。

実務での位置づけ

現実の運用では、MAC は DAC の代わりではなく、その上に積むものです。

• DAC で所有者と基本権限を決める。

• その上で MAC でプロセス単位の行動範囲を削る。

たとえば /srv/appdata をアプリ専用ユーザーに所有させるのは DAC の仕事です。その上で、AppArmor によって /srv/appdata 以外へ書き込めないようにするのが MAC の仕事です。この二重化が効いてきます。

Ubuntu では SELinux も使えますが、標準サポートの中心は AppArmor です。Ubuntu のセキュリティ文書でも、AppArmor は既定、SELinux は community-supported で、Ubuntu の推奨 MAC は AppArmor だと整理されています。

まとめ

DAC が利用者単位で「誰に何を許可するか」を管理する仕組みだとすれば、AppArmor のような MAC は、プロセス単位で「そのプログラムに何を許すか」を縛る仕組みです。この違いは、Linux のアクセス制御を理解するうえでかなり重要です。権限を持つ利用者が操作したとしても、プロセス自体に許されていない動作は実行できない。そこに、MAC を学ぶ意味があります。

Ubuntu VM で AppArmor を試すと、この考え方は抽象論ではなく、かなり具体的に見えてきます。enforce では実際に制限がかかり、complain では制限候補がログとして見える。つまり AppArmor は、いきなり厳しく縛るだけの仕組みではなく、観察しながら絞り込んでいける、運用に寄った MAC です。

Linux の防御は、機能を増やすことそのものが本質ではありません。重要なのは、必要な動作だけを通し、それ以外を許さないことです。AppArmor は、その原則を現実のシステムに落とし込むための、実用的で学びやすい強制アクセス制御の入口です。Ubuntu VM で一度手を動かしてみると、「制御する」とはどういうことかが、権限設定だけでは見えなかった輪郭を持って理解できるはずです。