32bit FreeBSD13.2 は、OSに脆弱性が見つかった時、ソースコードからカーネルをビルドし直す必要があり、その実験メモ。
インストール直後の脆弱性レポートは以下の通り。ほとんど害が無いレベルの脆弱性なので、室内で使う分には大した内容じゃありませんが、公開サーバーとして利用するかどうかは微妙。ファイヤーウォールとアクセスコントロールを行えば大丈夫そうな気がしますが。
FreeBSD-kernel-13.2 is vulnerable: FreeBSD -- Wi-Fi encryption bypass CVE: CVE-2022-47522 WWW: https://vuxml.FreeBSD.org/freebsd/924cb116-4d35-11ee-8e38-002590c1f29c.html FreeBSD -- pf incorrectly handles multiple IPv6 fragment headers CVE: CVE-2023-4809 WWW: https://vuxml.FreeBSD.org/freebsd/d35373ae-4d34-11ee-8e38-002590c1f29c.html FreeBSD -- Remote denial of service in IPv6 fragment reassembly CVE: CVE-2023-3107 WWW: https://vuxml.FreeBSD.org/freebsd/3dabf5b8-47c0-11ee-8e38-002590c1f29c.html FreeBSD -- arm64 boot CPUs may lack speculative execution protections CVE: CVE-2023-5370 WWW: https://vuxml.FreeBSD.org/freebsd/162a675b-6251-11ee-8e38-002590c1f29c.html FreeBSD -- copy_file_range insufficient capability rights check CVE: CVE-2023-5369 WWW: https://vuxml.FreeBSD.org/freebsd/e261e71c-6250-11ee-8e38-002590c1f29c.html FreeBSD -- msdosfs data disclosure CVE: CVE-2023-5368 WWW: https://vuxml.FreeBSD.org/freebsd/fefcd340-624f-11ee-8e38-002590c1f29c.html 6 problem(s) in 1 installed package(s) found. FreeBSD-13.2 is vulnerable: FreeBSD -- Network authentication attack via pam_krb5 CVE: CVE-2023-3326 WWW: https://vuxml.FreeBSD.org/freebsd/9b0d9832-47c1-11ee-8e38-002590c1f29c.html FreeBSD -- Potential remote code execution via ssh-agent forwarding CVE: CVE-2023-38408 WWW: https://vuxml.FreeBSD.org/freebsd/291d0953-47c1-11ee-8e38-002590c1f29c.html FreeBSD -- bhyve privileged guest escape via fwctl CVE: CVE-2023-3494 WWW: https://vuxml.FreeBSD.org/freebsd/ab437561-47c0-11ee-8e38-002590c1f29c.html FreeBSD -- Network authentication attack via pam_krb5 CVE: CVE-2023-3326 WWW: https://vuxml.FreeBSD.org/freebsd/41af0277-47bf-11ee-8e38-002590c1f29c.html 4 problem(s) in 1 installed package(s) found.
脆弱性対策のやり方を確認するため、Raspberry Pi で、32bit FreeBSD カーネルをソースからビルドするテストしようとすると、結構大変。
SDメモリ上でソースビルドを行うと、大量のファイル書き換えが発生するので、ビルド数回でSDメモリの寿命を迎える可能性があり、ソースからビルドを前提とするならHDD上にビルド関連ファイル（/usr/src, /usr/obj）を置きたい。そうすると、USB HDDを接続することになります。私の手持ちパーツでは、
まず、RPI4 では32bit FreeBSD は準備されていないので、実験不可。
RPI3は32/64bit 両方いけそうですが、電源容量の問題か、HDDからブートしてくれない。
RPI2は、HDDを別電源にすると、32bit FreeBSD 13.2 が起動しました。
ということで、RPI2 V1.2 の USB 2.0 ポートに接続した 3.5inch に ARM7 GENERIC イメージから書き込んだFreeBSD13.2 に、git から ソースコードをインストール。
そのあとの手順は、
- root にて、
- /usr/src に移動して、git pull でソースを最新にする。
- Makefile のコメントを読む。「# kernel – buildkernel + installkernel.」となっているので、これを行えば、いい。
- 「make -j4 kernel」 とコマンドを発行。-j4 は RPI のCPUコアを4個使う指定。オプションを付けないと、1個だけ使用。RPI2 は4コアなので、全部使っちゃう。ただし、メモリに余裕が無いと、スワップして逆に遅くなるので、-j2, -j4 と上げてゆきました。使用メモリはコア1～4であまり変化しなかった。
- 2,3 時間は掛かるので、放置しておいたところ、タイムスタンプを見ると、3時間くらいでビルドとインストールが終了していました。
- OS再起動。
- uname -a の結果が以下で、13.2-p4 に上がっていることを確認できました。
FreeBSD rpi2.lifewithunix.jp 13.2-RELEASE-p4 FreeBSD 13.2-RELEASE-p4 releng/13.2-n254638-d20ece445acf GENERIC arm
あとは、明日朝届くセキュリティーレポートに上記脆弱性が残っているかどうかの確認が残っているだけ。
約10年ぶりにFreeBSDカーネルのビルドをしました。昔は、PPPoEドライバーを組み込んだり、不要なドライバーを削除してカーネルが占有するメモリを減らすためによくやってたんですが、今は便利な時代。
作業前に心配だったのが、USB HDD のアクセス速度。RPI2の USBは、USB2.0なので、SDメモリより圧倒的に遅いんじゃないかと。
やってみると、全然そんなことは無く、コマンドを叩く人間にとっては遅延なくレスポンスがある。ファイル一個が200MBもあるようなテキストファイルを開くとどうなるかわかりませんけど、ビルドに関しても問題なし。
というのは、ビルドに使うソースファイル単体のサイズは小さく、コンパイルが始まるときに一度読み込んでしまえば、その後のアクセスは不要。ビルド中は、リロケータブルファイルのような中間ファイルを書き込むときにHDDアクセスが生じるものの、HDD負荷はだいたい10%以下。USBインタフェースの速度はあまり気にする必要なさそうと実感。
ただ、Raspberry Pi にHDDは どうよ！ってことは思いますけどね。せっかくの低消費電力性を無駄にしている感があります。RPI2は1A電源なので最大5W。HDDが約10Wで、合計15W。3A電源の RPI4 も最大15W。RPI4はCPUが発熱しているのに対して、RPI2+HDDは、HDDが発熱する。
ソースレベル管理が必要な 32bit FreeBSD の脆弱性対策はこんな感じ。
しかし、外付けHDD使ってまで、RPI2 を使う必要あるの？と自問する。
HDDベースのサーバーでクロスビルドして、そこから FreeBSD/arm にバイナリーインストールできれば、従来通りって思うのですが、その環境構築はまた大変そう。
余談ですが、-j2 オプションで、make buildworld をやってみたら、ビルド完了するまで約36時間かかりました。-j4 オプションでCPU全部使ったらどうなるか？とやってみたら、見事に約半分の18時間くらい。