fbpx

[和訳] テストを通したシステム考古学 #getchef

Chef

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本稿は System Archaeology Through Testing (2015/05/15) の和訳です。

みなさんご存知の通り、私はChefのAudit Modeを使ってCookbookでCISベンチマーク (訳注:和訳)を実装しました。最近、Ubuntu 14.04に対応しました。本稿では、ベンチマークの推奨を背景とした本質的なOSレベルの設定についての発見と、ユーザがChefを使って改善する方法を共有したいと思います。

Ubuntu 14.04のCISベンチマークの13.7項では次のように述べられています。

解説: システム管理者がユーザのホームディレクトリに安全なパーミッションを設定している限り、ユーザはそれらを容易に上書きできます。

理由: グループまたはあらゆるユーザが書き込み可能なユーザのホームディレクトリは、悪意あるユーザによって他のユーザのデータを盗んだり変更したりでき、他のユーザのシステム権限を奪ったりできます。

ChefのAudit Modeでこれを実装するには、次のようにControlを記述します。


control_group '13 Review User and Group Settings' do
let(:user_dirs) do
ud = {}
Etc::Passwd.each do |u|
unless (%w(root halt sync shutdown).include?(u.name) ||
u.shell =~ /(\/sbin\/nologin|\/bin\/false)/)
ud[u.name] = u.dir
end
end
ud
end

control '13.7 Check Permissions on User Home Directories' do
it 'has correct permissions for all non-system user home directories' do
user_dirs.each_value do |user_dir|
if File.directory?(user_dir)
expect(file(user_dir)).to_not be_writable.by('group')
expect(file(user_dir)).to_not be_readable.by('others')
expect(file(user_dir)).to_not be_writable.by('others')
expect(file(user_dir)).to_not be_executable.by('others')
end
end
end
end
end

ほら、user_dirsは、このファイルのControl Group内の他のテストでも使われています。これは「非システム」ユーザ----特にroot、halt、sync、shutdown、シェルがnologinやfalseに設定されているユーザ----に対してのみ、ホームディレクトリの確認をしています。Ubuntu 14.04に対して公開している「bento」boxを使ってみます。残念ながら、デフォルトインストールでは、このテストは失敗します。


1) 13 Review User and Group Settings 13.7 Check Permissions on User Home Directories has correct permissions for all non-system user home directories
Failure/Error: expect(file(user_dir)).to_not be_writable.by('group')
pected File "/var/lib/libuuid" not to be writable

これは驚くべきことでした。「システム」のホームディレクトリが/var/libだって？ このディレクトリはなぜグループが書き込み可能なのでしょうか？


$ ls -ld /var/lib/libuuid
drwxrwsr-x 2 libuuid libuuid 4096 Apr 16 2014 /var/lib/libuuid

$ getent passwd | grep /var/lib/libuuid
libuuid:x:100:101::/var/lib/libuuid:

これは低いUIDとGIDを持つ、libuuid「システム」ユーザです。しかし、このユーザとこのディレクトリを作成したのは何者でしょうか？ libuuidパッケージがこのディレクトリを作成し、通常Debianベースのシステムに存在しているものです。


$ dpkg -S /var/lib/libuuid
dpkg-query: no path found matching pattern /var/lib/libuuid

どのパッケージもこのディレクトリを所有していません。2つの「uuid」パッケージがインストールされているのに。


$ dpkg -l | grep uuid
ii libuuid1:amd64 2.20.1-5.1ubuntu20 amd64 Universally Unique ID library
ii uuid-runtime 2.20.1-5.1ubuntu20 amd64 runtime components for the Universally Unique ID library

これらはより大きなutil-linuxパッケージの一部です。これらのパッケージ自体はこのディレクトリを管理していないので、おそらくpostinstスクリプトが行っているはずです。


$ grep /var/lib/libuuid /var/lib/dpkg/info/*.postinst
libuuid1:amd64.postinst: useradd -d /var/lib/libuuid -K UID_MIN=$FIRST_SYSTEM_UID -K UID_MAX=$LAST_SYSTEM_UID -g libuuid libuuid
libuuid1:amd64.postinst:mkdir -p /var/lib/libuuid
libuuid1:amd64.postinst:chown libuuid:libuuid /var/lib/libuuid
libuuid1:amd64.postinst:chmod 2775 /var/lib/libuuid
libuuid1:amd64.postrm: rm -rf /var/lib/libuuid
uuid-runtime.postinst: Useradd -d /var/lib/libuuid -K UID_MIN=1 -K UID_MAX=499 -g libuuid libuuid

libuuid1パッケージをインストールすると、libuuidユーザを作成し、そのホームディレクトリを作成し、所有者とグループを設定し、パーミッションを2775に設定します。このモードはグループ書き込み可能なので、Audit Controlテストが失敗する原因となっています。これはめずらしいことではなく、Ubuntu/Debianの他のパッケージやRHELやその他のものでも、パッケージのためのユーザを作成したり、何かサービスを提供したり、その他のシステムへの変更を行ったりします。

この発見をどのように修正したらいいでしょうか？ 問題あるパッケージを削除してしまえるでしょうか？


$ sudo dpkg --purge libuuid1 uuid-runtime
dpkg: dependency problems prevent removal of libuuid1:amd64:
rsyslog depends on libuuid1 (>= 2.16).
util-linux depends on libuuid1 (>= 2.16).
libcryptsetup4 depends on libuuid1 (>= 2.16).
e2fsprogs depends on libuuid1 (>= 2.16).
libblkid1:amd64 depends on libuuid1 (>= 2.16).
wget depends on libuuid1 (>= 2.16).
libxapian22 depends on libuuid1 (>= 2.16).
libparted0debian1:amd64 depends on libuuid1 (>= 2.16).

dpkg: error processing package libuuid1:amd64 (--purge):
dependency problems - not removing
(Reading database ... 48682 files and directories currently installed.)
Removing uuid-runtime (2.20.1-5.1ubuntu20) ...
Purging configuration files for uuid-runtime (2.20.1-5.1ubuntu20) ...
Processing triggers for man-db (2.6.7.1-1) ...
Errors were encountered while processing:
libuuid1:amd64

ほら、uuid-runtimeはきれいに削除できましたが、このディレクトリを削除するpostrmを持っているlibuuid1は他の必須パッケージから依存されています。この点において、uuid-runtimeパッケージを削除しただけではControl (13.7)をパスできません。取りうる修正は次の通りです。

  1. libuuidユーザとグループを削除します。なぜlibuuid1がこのユーザを作ったのかはっきりしていないので、いくつかのライブラリに問題を起こしそうです。
  2. 問題のパーミッションであるg+wsを削除するために、/var/lib/libuuidのパーミッションを変更します。
  3. libuuidユーザのホームディレクトリをグループが書き込みできないパーミッションのどこか別のところに変更します。/var/libということは、libuuidのホームディレクトリに直接書き込むプログラムに対して、予期せぬ副作用を起こしそうです。
  4. libuuidユーザを、root、halt、sync、shutdownユーザと同じになるように、Audit Modeのテストを変更します。
  5. libuuidユーザに非ログインシェルを設定します。Ubuntu 14.04に対するこの提案をバグレポートしました。最近バージョン8がリリースされたDebian経由で、Ubuntuの後のバージョンで修正されるでしょう。

audit-cis Cookbook自体はAudit Modeのテストを実装しているだけなので、この発見に対する修正はありません。エンドユーザが自身のCookbookにおいて修正しましょう。


user 'libuuid' do
shell '/bin/false'
home '/var/lib/libuuid'
system true
end

新しく公開したlibuuid-user Cookbookでは、libuuidユーザを管理することでこの問題を修正し、2つの検証も提供しています。

  1. Audit Modeを使ってユーザのシェルが/bin/falseであることを検証します。
  2. Serverspecを使ってrootユーザがsuでlibuuidユーザになれないことを検証します。

postinstはlibuuidユーザのUIDやlibuuidグループのGIDを指定していないことに、誰も言及していないことに注意が必要です。このテストでは、前述の通りuuid-runtimeパッケージを削除し、再インストールしてユーザを再作成しています。UIDが異なっているのに、ホームディレクトリが変更なしで既に存在しています。これはControl「13.13 ユーザのホームディレクトリの所有者の確認」が失敗する原因となります。前述のlibuuid-user CookbookのRecipeは、この普通でない状況によって起きる問題を取り扱いません。しかし、前述の取りうる修正手順の一覧を考慮するときに、気がつく何かがあるでしょう。

新規CTA