Capability Moduleを有効にしたところBINDが起動しない不具合が発生

「前回の投稿」でカーネルを再構築してCapability Moduleを有効にしましたが、思わぬ不具合が出たのでメモとして残しておきます。

再起動は問題なくできたのですがBINDの起動の際に以下のエラーで起動ができないという現象に遭遇しました。

エラーの内容と対処法

起動時のエラーは以下のとおりです。

named を起動中: named: capset failed: Operation not permitted: please ensure that the capset kernel module is loaded.  see insmod(8)

環境は前回の投稿で書きましたが「64bitのCentOS 5.9でカーネルは2.6.18、Clam AntiVirus 9.7」という組み合わせです。

対処法を検索してみたところ、同様の報告が海外のフォーラムで盛んに議論されていました。
いくつか紹介します。

libcapによるバグという報告

http://fixunix.com/kernel/384216-re-2-6-25-kernel-problems-capabilities.html
テストとしてlibcapの1.10 、1.92、1.97のバージョンをインストールしてみましたが改善しませんでした。

その他の報告

ハードウエアアクセラレータによるバグという報告
SELinuxとの依存関係によるバグという報告
commoncap.koとの読み込み順序による不具合という報告
公式のvanillaカーネルからコンパイルをすると動作するとの報告
64bit特有のバグという報告

これらの情報を元に対策を取りましたが、カーネルのコンパイル時に失敗するか、BINDの不具合が出て先に進みません。

実は前回の投稿をする前に「32bitのCentOS5.8でカーネルが2.6.17」という環境でCapability Moduleを有効にするテストしていたのですが、その環境では問題なくCapability ModuleもBINDも動作しています。

カーネルコンパイル時のエラー

SELinuxと競合しているということでNSA SELinux Supportを全て無効にし、Default Linux CapabilitiesをMとしてコンパイルした際のエラー。

security/built-in.o: In function `security_ops_task_setrlimit':
/home/www/rpmbuild/BUILD/kernel-2.6.18/linux-2.6.18-371.4.1.el5.x86_64/security/security.c:47: undefined reference to `selinux_ops'
/home/www/rpmbuild/BUILD/kernel-2.6.18/linux-2.6.18-371.4.1.el5.x86_64/security/security.c:48: undefined reference to `selinux_task_setrlimit'
make: *** [.tmp_vmlinux1] エラー 1

コンパイルに成功しても「make modules_install」とした際に以下のエラーで止まることもありました。

WARNING: /lib/modules/2.6.18-371.4.1.el5xen/kernel/security/commoncap.ko needs unknown symbol dac_mmap_min_addr
WARNING: /lib/modules/2.6.18-371.4.1.el5xen/kernel/security/commoncap.ko needs unknown symbol dmesg_restrict

CONFIG_SECURITY_DMESG_RESTRICTやCONFIG_LSM_MMAP_MIN_ADDRと競合しているという情報もありましたが、こちらを無効にしても同じようにエラーが出ました。

ちなみにdazukoのコンパイル時のオプションに、他のローダブルセキュリティーモジュールとの競合を回避するというものがあります。

試しに以下のオプションでコンパイルをしたところ正常に終了しました。

# ./configure --enable-syscalls --mapfile=/boot/System.map-2.6.18-371.4.1.el5xen --disable-stacking

しかし、いざテストやインストールしたモジュールを取り込もうとするとシステムがシャットダウンするというバグが発生。恐らく、他のセキュリティーモジュールによって競合しているものと思われます。

もしもカーネルパニックが起こる場合は「--sct-readonly」というオプションを付けると改善するとありましたが、これも効果なしでした。

他にもDebianで使われるgrsecとも相性が悪く競合するとのことです。

ここで再考

Capability Moduleはカーネル2.6.25以前と、2.6.25以降で大きく機能が異なります。
さらに、2.6.38以降ではfanotifyという機能に取って代わられています。
どのみち限定的な環境でしか有効にできないのなら「とりあえず動作すれば良い」ということで、再びコンパイル作業を行い、モジュール化せずにカーネルに取り込むことにしました。（つまりデフォルトの設定に戻した）

以下、make menuconfigの際の、Security optionsです。

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
# CONFIG_SECURITY_SECLVL is not set
CONFIG_LSM_MMAP_MIN_ADDR=4096
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set

あたりまえですが、この設定ならCapability ModuleもBINDも正常に動作しています。

失敗した例ばかりで恐縮ですが、同じ悩みを持つ人の助けになればと思って公開します。
やはりファイルアクセスを制御するセキュリティモジュールという特性上、他のシステムと干渉しやすく、影響も大きいためできれば公式でサポートされた機能を利用するのが安心ですね。

その後、vanilla kernelで動作テストしたところ、問題なく動きました。
よく見たらDazukoのDownloadsにある「Target」にCentOSは無いので、そもそもサポートしていないのかもしれません。