AppArmorは強制アクセス制御(MAC:Mandatory access control)を提供する仕組みで、各プログラムにプロファイルを用意して、プログラムができることに制限を掛けている。システムはこの仕組みによって内外の脅威から保護されている。
Ubuntuが提供するパッケージにはプロファイルが含まれているから、通常の使い方ならば何も意識しなくても問題は起きないが、ちょっと変わったことをしようと思うとこのプロファイルから外れてしまい、プログラムが思い通りに動作しない。
今回は Kopano で LDAP認証しようとしたところで問題が発生した。最近ちょこちょこ見直すので、自分用に情報を整理。
Ubuntu documentation Community Help Wiki / AppArmor
Ubuntu Manpage / apparmor.d
AppArmorのプロファイル
AppArmorが利用するプロファイルは /etc/apparmor.d に配置されている。
各種プログラムの設定は、そのプログラムの名前で保存されている。
マニュアルはこちら。
Ubuntu Manpage / apparmor.d
プロファイルの中身
たとえば、/usr/sbin/kopano-serverならば、usr.sbin.kopano-server という名前でパッケージに含まれている(/ を . に置き換える)。
/etc/apparmor.d/usr.sbin.kopano-server
#include <tunables/global>
/usr/sbin/kopano-server flags=(attach_disconnected) {
#include <abstractions/base>
#include <abstractions/nameservice>
#include <abstractions/user-tmp>
#include <abstractions/mysql>
capability chown,
capability dac_override,
capability dac_read_search,
capability setgid,
capability setuid,
network tcp,
/etc/kopano/debian-db.cfg r,
/etc/kopano/server.cfg r,
/usr/sbin/kopano-server r,
…
# Site-specific additions and overrides. See local/README for details.
#include <local/usr.sbin.kopano-server>
}
中身はなんとなくしか分からない。
#include
設定をまとめて取り込む記述。
tunables/global とか abstractions/mysql とかを取り込んでいる。何か便利なアプリケーションを使おうとしたとき、おまとめ設定を取り込めれば楽チン。
なお、kopano-server の設定は最後に
local/usr.sbin.kopano-server
を include している。kopano-server の設定を変えたことで何か特別に権限を付与するときには /etc/apparmor.d/local/usr.sbin.kopano-server にそのことを書き込めば良いようになっている。
network
ネットワークに関する制限をざっくり指定できる。
この例では、tcp を許可している。
network tcp,
他のルール、たとえば dhcpd を見ると以下のような記述もあった。
network inet raw,
network packet packet,
network packet raw,
inet は IPv4 の raw データグラムの送受信を許可するなど。
access permissions
この例では
/etc/kopano/debian-db.cfg r,
/etc/kopano/server.cfg r,
/usr/sbin/kopano-server r,
とか書かれている。設定用のファイルに対する read な権限をこうして渡し、アクセスできるようにしていた。
r はRead mode 、w は Write mode となっておりマニュアルを検索するとその近辺に色々な権限が書かれている。
Samba ad dc を利用した認証のために /etc/kopano/ldap.cfg というファイルを作ったが、そのファイル自体と、その中で include しているファイルなど関係するファイルすべてに r の権限を渡しておかないとファイルを読むことすらしなかった。
具体的にはこんな権限を追加している。
/etc/apparmor.d/local/usr.sbin.kopano-server
/etc/kopano/ldap.cfg r,
/usr/share/kopano/ldap.active-directory.cfg r,
/usr/share/kopano/ldap.propmap.cfg r,
他のルール、たとえば dhcpd を見ると以下のような記述もあった。
/var/lib/dhcp/dhcpd{,6}.leases* lrw,
capability
Capability ってのは能力とか才能のこと。Linuxにおいては、rootの持つすべての権限をグループ分けしたもので、スレッドにグループ単位で付与できるものらしい。上の例では
capability chown,
というような書き方で付与している。
プログラムが引き起こしたケーパビリティに関する問題は、例えばこのような形で報告される。
Jun 16 03:46:17 hogeserver kernel: [ 44.708748] audit: type=1400 audit(1560624377.950:27): apparmor="DENIED" operation="capable" profile="/usr/sbin/kopano-server" pid=2033 comm="kopano-server" capability=24 capname="sys_resource"
最後の方にこんな情報が出力されている。
capability=24
capname="sys_resource"
何故24番なのか。
/usr/include/linux/capability.h
#define CAP_SYS_RESOURCE 24
このように定義されている。マニュアルに CAP_SYS_RESOURCE の項目があり、この設定値が示すケーパビリティが書かれている。
ubuntu manuals / capabilities - Linux のケーパビリティ (capability) の概要
このことから、CAP_+capnameでマニュアルを見れば良さそうなことが分かる。
先ほどのログが出力していた問題を解消するには、以下を追記しておけば良い。
/etc/apparmor.d/local/usr.sbin.kopano-server
capability sys_resource,
これによって付与されるケーパビリティはマニュアルに書かれているけど、中身は正直なところよく分からない…何か大切なことをしているのでしょう。
設定の反映
2019/11/23追記
設定を変更した後、AppArmorにこれを反映させるのには以下が使えそう。
$ sudo systemctl reload apparmor
実行後にsyslogを見ると、プロファイルが読み込まれているのがわかる。
Nov 23 07:45:12 hogeserver apparmor[32118]: * Reloading AppArmor profiles
ツールを利用した AppArmor の設定
ログを見てすべてに対応できれば良いのだが、書き方がよく分からないときにはツールを利用することができる。
具体的にはケーパビリティに sys_resource を与えたかったのだが、今こうして落ち着いてみればどう書いたら良いか分かるものの、ログを見たそのときにはどうすりゃいいのかがよく分からない状態に陥っていた。
ツールのインストール
ツールは以下でインストールする。
$ sudo apt install apparmor-utils
aa-logprof, aa-complain, aa-enfoce
プログラムは aa-complain コマンドで complain モードにすると、違反する部分を許容して動作をさせつつ、【違反している箇所】をログを出力するようになる。
ここでは、kopano-serverを complain モードにしている。
$ sudo aa-complain /usr/sbin/kopano-server
こうして complain モードに変更した後に、kopano-server が LDAPS で Samba ad dc にアクセスするようなコマンドを実行してみた。
$ sudo kopano-admin -l -v
User list for Default(6):
Username Fullname Homeserver
----------------------------------------------------
SYSTEM SYSTEM Kopano
Administrator Administrator
…
これで syslog に違反する部分に関するログが出力される。この他にも、できるだけ多くの機能を complain モードで実行しておくと良い。
その後に aa-logprof を呼び出すと、ログにある【違反している箇所】からルールを生成(既にあるなら追記)してくれる。
$ sudo aa-logprof
ルールができたらそれを読み込ませる。
$ sudo systemctl reload apparmor
※本当は、ターゲットとなるルールだけを読み込むこともできるが、すべてを読み込み直してもそんなに時間はかからない。
これで違反していた箇所が許容されるようになる。
通常運用で忘れないようにしたいのは、モードを enfoce に戻して発生しうる何らかの脅威から保護すること。
ここでは、kopano-server を enfoce モードに戻している。
$ sudo aa-enfoce /usr/sbin/kopano-server
aa-genprof
ルールを新たに生成するのに使うみたい。aa-logprof を高度にラッピングしているらしいが、今回 aa-logprof を検索して初めて知ったツールで、試せていない。
Debian 管理者ハンドブック / 14.4. AppArmor の紹介
$ sudo aa-genprof kopano-server
実際のところ aa-genprof は aa-logprof の洗練されたラッパーに過ぎません。すなわち aa-genprof は空のプロファイルを作成し、complain モードでそのプロファイルを読み込み、aa-logprof を実行しているだけです。
管理者ハンドブックにこのように書かれている。うまく使えば、プロファイルを正しく生成できそう。
さいごに
AppArmorについては、このサイトでも過去に数回触れている。
- AirPrint非対応のプリンタをUbuntuに登録し、Avahiでプリントサービスを提供する。パッケージで用意されていたプロファイルを無意識に登録。
- dhcpdでIPアドレスを振り出したらSamba ad dcに登録したいが、登録用スクリプト呼び出しを無効化された。多分これで動くだろうというプロファイルを作成(汗
- Kopanoインストール後に時々"DENIED"されていることに気付いた。rootへのメールがKopanoでフォルダ振り分けできないので色々原因を探っていたときににプロファイルを作成したが、この問題への対策になっているのかどうかが分かっていない(汗
振り返って考えてみれば、プログラムがどこに何のアクセスをしに行くのかを完全に把握できていないと完全な設定ができないので、こうすればいいよね?と書いて示すことはあくまでも「そのときに気付くことができたこと」だけであって、全部ではないかもしれない。また、もしかしたら何かの脅威によるアクセスを不用意に許可してしまっているのかもしれない。
だから自分でルールを作るときには毎回 (汗 をかいているのだった。
コメントはこちらから お気軽にどうぞ ~ 投稿に関するご意見・感想・他