11 月末ぐらいから、 bind9 のログが出力できないとか統計情報のファイルが作れないという状況になっていたのですが…。
ログに関しては syslog 経由で出すように設定変えて凌いだんですが、統計情報（ rndc stats で出力されるやつ）が出力できないのが正常にならなくて、「 bind の設定いじってないのに、なんででなくなった？」と悩んでいたわけです。
で、今日。ふと思い立って出力ファイル名である named.stats をキーにして、/varlog/syslog に grep を実行してみたところ…。
Dec 6 10:20:14 nexus01 kernel: [927197.495080] audit: type=1400 audit(1512523214.458:3455): apparmor="DENIED" operation="open" profile="/usr/sbin/named" name="/var/log/bind9/named.stats" pid=13306 comm="named" requested_mask="ac" denied_mask="ac" fsuid=109 ouid=109
Dec 6 10:25:01 nexus01 kernel: [927484.822757] audit: type=1400 audit(1512523501.782:3456): apparmor="DENIED" operation="open" profile="/usr/sbin/named" name="/var/log/bind9/named.stats" pid=13306 comm="named" requested_mask="ac" denied_mask="ac" fsuid=109 ouid=109
apparmor って、コレかよ、原因は…。 orz
「何かの依存関係で、インストールされてたなぁ…」というのは、微かに記憶の片隅にあったのだけど、これが原因になっていたとは、予想だにせず。
パッケージのインストールログ（ /var/log/aptitude ）を漁ってみたら、確かにインストールしてるし、bind のログ出力周りがおかしくなったタイミングとインストールした日時が、ほぼ合致しているので、間違いなく AppArmor をインストールしたことの影響だったようです。
Aptitude 0.8.10: log report
Fri, Nov 24 2017 14:42:09 +0900
IMPORTANT: this log only lists intended actions; actions which fail
due to dpkg problems may not be completed.
Will install 8 packages, and remove 0 packages.
252 MB of disk space will be used
========================================
[HOLD, DEPENDENCIES] openssl:amd64 1.1.0f-5
[HOLD] libssl1.1:amd64 1.1.0f-3
[INSTALL] apparmor:amd64 2.11.1-3
[INSTALL] linux-compiler-gcc-7-x86:amd64 4.14-1~exp1
[INSTALL] linux-headers-4.14.0-trunk-amd64:amd64 4.14-1~exp1
[INSTALL] linux-headers-4.14.0-trunk-common:amd64 4.14-1~exp1
[INSTALL] linux-image-4.14.0-trunk-amd64:amd64 4.14-1~exp1
[INSTALL] linux-kbuild-4.14:amd64 4.14-1~exp1
[UPGRADE] libmariadbclient18:amd64 1:10.1.29-5 -> 1:10.1.29-6
[UPGRADE] mariadb-common:amd64 1:10.1.29-5 -> 1:10.1.29-6
========================================
Log complete.
===============================================================================
＃ bind9 側に何か変更があった？と思って調べてたんだけど、そちらは全部ハズレだったよ。
では、 AppArmor の設定を変えましょ
ということで、 AppArmor の設定を変更して、 rndc stats 実行時に正しく統計情報ファイルが出力されるようにしましょう、ということで設定ファイルをいじっていきます。
設定ファイルを弄る前に、現状 AppArmor での保護対象がどうなっているのかを確認。これは、 "apparmor_status" を実行すれば、以下のような結果が得られます。
nexus01:~# apparmor_status
apparmor module is loaded.
8 profiles are loaded.
8 profiles are in enforce mode.
/usr/bin/freshclam
/usr/bin/man
/usr/bin/man//filter
/usr/bin/man//groff
/usr/sbin/clamd
/usr/sbin/named
/usr/sbin/ntpd
/usr/sbin/tcpdump
0 profiles are in complain mode.
4 processes have profiles defined.
4 processes are in enforce mode.
/usr/bin/freshclam (5557)
/usr/sbin/clamd (520)
/usr/sbin/named (13306)
/usr/sbin/ntpd (909)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
"/usr/sbin/named" と、確かに表示されましたね。
で、いじるべき設定ファイルは、どこにあるかというと、
nexus01:~# dpkg -L bind9 | grep "apparmor"
/etc/apparmor.d
/etc/apparmor.d/force-complain
/etc/apparmor.d/local
/etc/apparmor.d/local/usr.sbin.named
/etc/apparmor.d/usr.sbin.named
bind9 パッケージ側のファイル一覧から、"/etc/apparmor.d/usr.sbin.named" か "/etc/apparmor.d/local/usr.sbin.named" のどちらかを修正すればいいようですが、ここでは "/etc/apparmor.d/local/usr.sbin.named" のほうを修正します。
今回は、 /var/log/bind9ディレクトリ内に named デーモンによるファイルの作成・出力、読み取りが出来るようにするために、以下のように設定。
nexus01:~# more /etc/apparmor.d/local/usr.sbin.named
# Site-specific additions and overrides for usr.sbin.named.
# For more details, please see /etc/apparmor.d/local/README.
/var/log/bind9/** lrw,
/var/log/bind9/ rw,
設定ファイルのほうの追記なり修正が終わったら"apparmor_parser -r /etc/apparmor.d/local/usr.sbin.named" で設定の再読込を行ってから、"rndc stats" を実行してエラーが表示されないことと、 /var/log/bind9/named.stats が更新されていることが確認できれば完了と。
Debian sid での AppArmor 対応
気になったので関連情報を少しあさってみたところ、今年の 8 月頃から apparmor をデフォトルトにしようという議論が始まっていて、
議論のきっかけはDebian開発者でもあり，Tails（匿名化/プライバシー保護を目的としたDebianベースのディストロ）開発者としても知られる"intrigeri"が，8月4日付けで開発者向けメーリングリストに投稿したポストに端を発している。
[From 2017年9月25日 AppArmorをDebianでもデフォルトに!? ―Tails開発者が提言：Linux Daily Topics｜gihyo.jp … 技術評論社]
そこから3ヶ月近い議論の末に、 11 月初旬にデフォルトパッケージとして有効化された、という流れのようです。
intrigeri:
> The next upload of the linux-image packages will "Recommends: apparmor".
Done ⇒ AppArmor is now enabled by default in sid.
Let the experiment begin!
[From Re: Let's enable AppArmor by default (why not?)]
AppArmor は、 RHEL/CentOS 系でいうところの SELinux に相当するもの。
ファイルの読み書きやネットワークアクセスなどプログラムの挙動を制御してセキュアに動かそうということを目的したものですから、デフォルトパッケージとして取り込まれる事自体は悪いことじゃないんですけど、今回のようにひょいっと適用されてしまうと、ちょっとびっくりしてしまいますね。
まぁ、そういうことがあるのも、承知の上で sid 使っているわけですが…。
sid での動作チェックやバグ出しを経て、 Debian 10 "buster" で正式に取り込まれる流れになっているんで、なんかおかしな挙動にブチ当たったら、バグレポートとかしてみましょうかね？
コメントする