2016.10.19

CentOS Linux SELinux コマンドサーバ

cronで/etc/updatedb.confが開けなくてメールがくる！対処法

narushima

○環境

・VMWarePlayer上のCentOS
・CentOSのバージョンは6.5（↓で確認）

[root@localhost ~]# cat /etc/issue
CentOS release 6.5 (Final)
Kernel \r on an \m

○現象

新しいメールが /var/spool/mail/root にあります
(英語表記だとYou have mail in /var/spool/mail/root)
という通知が毎日くる。

/var/spool/mail/rootの中身をcatで見てみるとこんな感じ↓

[root@localhost ~]# cat /var/spool/mail/root

From root@localhost.localdomain Fri Oct 7 10:14:02 2016
Return-Path: <root@localhost.localdomain>
X-Original-To: root
Delivered-To: root@localhost.localdomain
Received: by localhost.localdomain (Postfix, from userid 0)
id 5A9A960B1D; Fri, 7 Oct 2016 10:14:02 +0900 (JST)
From: Anacron <root@localhost.localdomain>
To: root@localhost.localdomain
Content-Type: text/plain; charset=”ANSI_X3.4-1968″
Subject: Anacron job ‘cron.daily’ on localhost.localdomain
Message-Id: <20161007011402.5A9A960B1D@localhost.localdomain>
Date: Fri, 7 Oct 2016 10:14:02 +0900 (JST)

/etc/cron.daily/mlocate.cron:

/usr/bin/updatedb: can not open `/etc/updatedb.conf’: Permission denied

○メールに書かれていること

毎日定期実行されているmlocate.cronによる/usr/bin/updatedbがうまくいっていない。
updatedbを行うときに設定ファイルである/etc/updatedb.confを開くためのパーミッションがないとのこと。
※updatedbコマンドは、ファイル検索コマンドであるlocateコマンドを実行するときに使われるデータベースの更新を行うコマンドである。

○対策

・メール内で言及されたファイルたちのパーミッションを調べてみる。

[root@localhost ~]# ls -l /etc/cron.daily/mlocate.cron /usr/bin/updatedb /etc/updatedb.conf
-rwxr-xr-x. 1 root root 174 9月 24 21:39 2012 /etc/cron.daily/mlocate.cron
-rw-r–r–. 1 root root 480 3月 23 02:51 2016 /etc/updatedb.conf
-rwxr-xr-x. 1 root root 40500 10月 10 18:05 2012 /usr/bin/updatedb

管理者には実行権限は与えられているので、手動で/usr/bin/updatedbを実行する分には問題なかった。
しかしこれではAnacronは/etc/updatedb.confを開けないないようである。
その他のユーザに実行権限を与えてみてば解決するのではないか、と考えパーミッションを変更してみる。

[root@localhost ~]# chmod 755 /etc/updatedb.conf
[root@localhost ~]# ls -l /etc/updatedb.conf
-rwxr-xr-x 1 root root 480 10月 16 03:33 2016 /etc/updatedb.conf

しかし結果は変わらず、メールはまたしばらくすると届いてしまう。

・対処法①

ただこのメールがうっとうしくて、別にupdatedbを定期実行しなくてもよいという人は

[root@localhost ~]# rm /etc/cron.daily/mlocate.cron

でmlocate.cronを削除してしまえばよい。
これでメールが送られてくることはなくなるだろう。

・対処法②

mlocate.cronファイルの中身を見てみると↓のようである。

[root@localhost ~]# cat /etc/cron.daily/mlocate.cron
#!/bin/sh
nodevs=$(< /proc/filesystems awk ‘$1 == “nodev” { print $2 }’) renice +19 -p $$ >/dev/null 2>&1
ionice -c2 -n7 -p $$ >/dev/null 2>&1
/usr/bin/updatedb -f “$nodevs”

ここで/usr/bin/updatedbが実行されるように指定してある。
これを実行しないようにコメントアウトしてしまえばよい。
viで/etc/cron.daily/mlocate.cronを開き

#!/bin/sh
#nodevs=$(< /proc/filesystems awk ‘$1 == “nodev” { print $2 }’) #renice +19 -p $$ >/dev/null 2>&1
#ionice -c2 -n7 -p $$ >/dev/null 2>&1
#/usr/bin/updatedb -f “$nodevs”

のようにコメントアウトしてしまえばよい。

・対処法③

SELinuxに目を付ける。
SELinuxというのは、簡単にいうとパーミッションより高度なアクセス制限機能を付加するモジュールのことである。
Linuxにおけるパーミッションは、一般ユーザなどに対しては非常に有効だが、root（管理者）には効かないという欠点がある。
SELinuxでは、httpやftpなどのプロセスごとに制限をかけれる機能と、rootも含むすべてのユーザに制限をかける機能が備わっている。

今回はこのSELinuxが、邪魔をしていると考えられる。

SELinuxでは、プロセスとリソースに対して「SELinuxセキュリティコンテキスト」という属性情報(ラベル) が付与される。
このセキュリティコンテキストに着目してみる。

「SELinuxセキュリティコンテキスト」は、ユーザ識別子、ロール識別子、タイプ識別子の3つで構成される。
ユーザ識別子とロール識別子は、それぞれRBACのユーザとロールを表し、タイプ識別子はTEのドメインとタイプを表す。

・TE では全てのプロセスに対して「ドメイン」と呼ばれるラベルを付加する。
・RBAC は「ロール」と呼ばれるドメインを集めたものを設定し、それをユーザに付加する仕組みである。ユーザは付加されたロール内のドメインの権限でのみファイルにアクセス可能になる。この機能により各ユーザ毎に細かく権限を付加、制限することが可能である。

ファイルやディレクトリのセキュリティコンテキストについては
ls -Zまたはls –contextで確認ができる。

manコマンドでlsコマンドの日本語のマニュアルページを見てみると-Zの項目がない…
しかたないので英語のマニュアルページを見てみると英語ページに載っていた！

[root@localhost ~]# LANG=C man ls
—–中略—–
ls -Z, –context
Display security context so it fits on most displays. Displays only
mode, user, group, security context and file name.
————–

このような記述である。
呼んでみると、「セキュリティコンテキストを表示するから、ほとんどのディスプレイにうまくはまる。モード、ユーザ、グループ、セキュリティコンテキストそしてファイル名のみ表示する。」
と書いてある。つまりはセキュリティコンテキストを表示できると書いてあるのだ。（翻訳が下手なことに対するツッコミは禁止。）

なので実際に実行してみる。

[root@localhost ~]# ls -Z /etc/cron.daily/mlocate.cron /etc/updatedb.conf /usr/bin/updatedb
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 /etc/cron.daily/mlocate.cron
-rwxr-xr-x. root root system_u:object_r:initrc_tmp_t:s0 /etc/updatedb.conf
-rwxr-xr-x. root root system_u:object_r:locate_exec_t:s0 /usr/bin/updatedb

このような表記である。

「system_u」はユーザを示し、「object_r」はロールを示す。
「bin_t」と「initrc_tmp_t」と「locate_exec_t」はタイプを示します。「s0」はレベルを示します。

ちなみに「/etc/updatedb.confが開けないメール」が届いたことがないCentOSに対してもこのコマンドを実行してみた。↓

[root@localhost ~]# ls -Z /etc/cron.daily/mlocate.cron /etc/updatedb.conf /usr/bin/updatedb
-rwxr-xr-x root root system_u:object_r:bin_t:s0 /etc/cron.daily/mlocate.cron
-rw-r–r– root root system_u:object_r:etc_t:s0 /etc/updatedb.conf
-rwxr-xr-x root root /usr/bin/updatedb

表記がことなる。該当の/etc/updatedb.confの欄のタイプが「etc_t」になっている。

この比較からコンテキストがinitrc_tmp_tタイプになっていることが原因であると考えられる。

ここで、このコンテキストをデフォルトの状態に復元してみる。
コマンドはrestoreconコマンドを使う。
restoreは日本語にすると「復元する」
conはcontext（コンテキスト）の略なので、コンテキストを復元するコマンドであることが分かる。

[root@localhost ~]# restorecon -RFv /etc
—中略—
restorecon reset /etc/updatedb.conf context system_u:object_r:initrc_tmp_t:s0->system_u:o
bject_r:etc_t:s0
———-

これで/etc/updatedb.confのinitrc_tmp_tタイプがetc_tタイプに復元されたようである。
Anacronはetc_tタイプのものにはアクセスができるようである。
現に自分の環境では、このエラーのメールが届くことはなくなった。
コンテキストのタイプが私のものと同じようであれば、この解決策でメールが届くことはなくなるだろう。

実行するコマンドのみまとめると↓

対処法①mlocate.cronごと削除してしまう方法

[root@localhost ~]# rm /etc/cron.daily/mlocate.cron

対処法②mlocate.cronの中身をコメントアウトしてしまう方法

[root@localhost ~]# vi /etc/cron.daily/mlocate.cron
～～～～～エディタ内～～～～～
#!/bin/sh
#nodevs=$(< /proc/filesystems awk ‘$1 == “nodev” { print $2 }’) #renice +19 -p $$ >/dev/null 2>&1
#ionice -c2 -n7 -p $$ >/dev/null 2>&1
#/usr/bin/updatedb -f “$nodevs”
～～～～～～～～～～～～～～～