いますぐ実践! Linuxシステム管理

いますぐ実践! Linux システム管理 / Vol.222 / 読者数:2146名

こんばんは、うすだです。

最近、超健康的な生活習慣が定着しつつあります。

ある日、夜9時〜10時くらいに眠くなり、ちょっと仮眠をとるつもりが、 夜中の2時〜3時まで寝てしまうことがありました。

それ以来、その時間帯に寝てしまって、起きたらそのまま朝まで、 という生活が続いています。

風呂も、入らずに寝て、起きてから入ります。
利点は、髪を洗った後寝ないため、朝、寝ぐせを整える必要がないということです。

その代わり、これが原因かどうかはわかりませんが、早くも汗疹ができてきました。

じゃあ、夜は体だけ洗って寝て、朝に髪を洗えばいいのではないか、 とも思いましたが、それはそれで面倒なので、実施には至っておりません。

まあ、悪い習慣ではないと思いますので、今後も継続していけるように、 あれこれ試行錯誤してみます。

…と、どうでもいい話は終わりにして、今回もはりきってまいります。

今回のお題 - Audit について学んでみる

前回、前々回と、「AppArmor」についてご説明しました。

Vol.220 - AppArmor をおおまかに理解する
http://www.usupi.org/sysad/220.html
Vol.221 - AppArmor を使ってみる
http://www.usupi.org/sysad/221.html

その際、AppArmor で許されていない操作をログに出力させ、 後でログを参照してプロファイルに反映させる、ということを行いました。

そして、そのログは、 いつもの「syslog」とは別の「audit」という機構を使って出力していました。
上記では、「auditd」を入れて動かしたらログに出力される、 ということをさらっと述べて終わりにしていました。

ですが、われわれシステム管理者は、 中身の知らないものを闇雲に使っていてはいけません。よね。 ざっくりとでもいいので、どういうものか理解してから使うべきです。

というわけで今回は、auditについて、ざっくり説明したいと思います。

Audit とは?

AppArmorは、「SELinux」などと同様、 「LSM(Linux Security Modules)」というカーネルの機能を利用して動作します。

各種システムコールでは、LSMのチェック関数を呼び出し、 そのシステムコールが許可されているかどうか確認します。

Linuxカーネルは、そのときの結果などを、コンソール出力とは別の領域に記録します。 それが Audit です。

そして、それらのうちどの種類のログを残すのか判別するフィルターが、 カーネル内部にあるため、必要な情報だけを残すことができます。

ただ、そのままでは、カーネル内部の領域に延々と記録されていくため、 そのうち溢れてしまいます。そこで、auditdというデーモンが、 カーネルからその情報を読み出して、ログに出力します。

auditd は、RedHat系なら「audit」、 Debian系なら「auditd」という名のパッケージに含まれます。もしなければ、 いつもの手順でインストールをしてください。

  $ sudo apt-get install auditd   (Debian系の場合)
  # yum install audit             (RedHat系の場合)

出力先は、大抵「/var/log/audit/audit.log」になっています。
内容が内容だけに、rootのひとしか読めない権限に設定されています。

auditd の起動

auditd は、パッケージをインストールしたら自動起動されるように設定される… と思いますが、念のため確認しておきましょう。
直接的には、「/etc/rc数字.d/S」で始まるスクリプトがあれば、 自動的に起動されるはずです。

  $ ls /etc/rc?.d/S*auditd
  /etc/rc2.d/S37auditd  /etc/rc4.d/S37auditd
  /etc/rc3.d/S37auditd  /etc/rc5.d/S37auditd

Fedoraの場合は、「systemd」で有効になっているかどうか確認します。

  # systemctl --all list-units | grep audit
  auditd.service  loaded active running  Security Auditing Service
  # systemctl status auditd.service
  auditd.service - Security Auditing Service
    Loaded: loaded (/lib/systemd/system/auditd.service; enabled)
    Active: active (running) since Sun, 19 Feb 2012 ...後略...
  Main PID: 620 (auditd)
    CGroup: name=systemd:/system/auditd.service
            ├ 620 /sbin/auditd -n
            ├ 635 /sbin/audispd
            └ 640 /usr/sbin/sedispatch

もっと直接的には、「ps」コマンドで確認できます。

  $ ps -C auditd
    PID TTY          TIME CMD
   数字 ?        00:00:01 auditd

auditd の設定

auditdの設定ファイルは、「/etc/audit/auditd.conf」です。
ですが、特に変わった設定を必要とするのでなければ、 触る余地はあまりないはずです。
触る可能性のありそうなキーワードを以下に示します。

  log_file             ログファイル名
  max_log_file         ログファイルの最大サイズ(MB)
  max_log_file_action  最大サイズに達したときの動作
  num_logs             ログファイルの個数
  space_left           最小の空き容量(MB)
  space_left_action    ディスクの空き容量が足りないときの動作

auditdは「log_file」で指定したログファイルに記録します。
ログファイルのサイズが「max_log_file」に達したら、なんらかの対処をします。 その方法を「max_log_file_action」で指定します。 基本的には「rotate」させますが、「syslog」に出力するなども可能です。
ローテートさせる場合、「num_logs」の個数までが保存されます。

また、ディスクそのものの空き容量が、「space_left」で指定したサイズを下回ったら、 「space_left_action」で指定した動作を行います。
デフォルトの設定では、75MBを下回ったら、「syslog」に出力します。

他にも、キーワードがいくつかあります。詳細は、 オンラインマニュアル(man auditd.conf)を参照してください。

auditctl でフィルタリング

カーネル内部にあるフィルターは、「auditctl」コマンドで参照や変更ができます。 参照するには、「-l」オプションをつけて実行します。
(以降、プロンプトが # の部分は、適時 sudo を補ってください。)

  # auditctl -l
  No rules

とりあえずは、からっぽのようです。
フィルターの追加や削除を行うには、以下の形式で実行します。

  auditctl -a リスト,アクション [オプション...]
  auditctl -A リスト,アクション [オプション...]
  auditctl -d リスト,アクション [オプション...]
  auditctl -D

お察しの通り、「-a」もしくは「-A」オプションで追加します。-aの場合は末尾に、 -Aの場合は先頭に追加します。そして、「-d」で削除します。

「リスト」には、以下のいずれかを指定します。

  task     プロセス生成時(forkかclone)
  exit     システムコール終了時
  user     アプリケーションが生成するログを対象とする
  exclude  この条件の時は除外

「アクション」には、出力する「always」か出力しない「never」を指定します。
「オプション」には、以下を複数指定できます。

  -S システムコール名
  -F 条件式

「条件式」に指定できる式やフィールドは、たくさんあります。
詳細は、オンラインマニュアル(man auditctl)を参照してください。

 

というわけで、簡単に例を示します。
/etc/resolv.conf を参照したときログに残したい場合は、以下のように実行します。

  # auditctl -a exit,always -S open -F path=/etc/resolv.conf

/home/usu に書き込まれたときログに残したければ、以下を実行します。

  # auditctl -a exit,always -F dir=/home/usu -F perm=w

そのルールを消したい場合は、「-a」や「-A」を「-d」に置き換えて実行します。

  # auditctl -d exit,always -F dir=/home/usu -F perm=w

 

ただし、auditctlコマンドを実行して設定したフィルターは、 システムの再起動などで失われてしまいます。

これらの設定を恒久的に残したい場合は、「/etc/audit/audit.rules」に記述します。 最初の auditctl を除いた分を指定します。

おわりに

以上、またまた駆け足でしたが、audit について簡単にご紹介しました。

基本的にはデフォルトの設定のままで十分使えます。
ですが、どのような原理で動作し、どのように設定できるのかは、 実際にいじくってみないとなかなか理解できないのではないかと思います。

あたりさわりのない程度に、いじくってみてください。

宿題の答え

前回の宿題は、

  シンボリックリンクやハードリンクのファイルに対してAppArmorがどの
  ように動作するか、確認してみましょう。

でした。

まず、対象のプログラムそのものがシンボリックリンクだった場合、 どうなるか見てみましょう。

シンボリックリンクのファイルを引数にして aa-autodep コマンドを実行すると、 実体の方のパスに書き換えられました。

  $ ls -l /foo/bar/buz
  lrwxrwxrwx 1 usu  usu  8  6月 16 23:45 buz -> buz_real
  $ sudo aa-autodep /foo/bar/buz
  Writing updated profile for /foo/bar/buz_real
  $ ls /etc/apparmor.d/foo*
  foo.bar.buz_real

作成されたプロファイルのパスを、 無理やりシンボリックリンク名に変更して aa-enforce すると、実行されますが、 当然ながら実際のプログラムには反映されませんでした。

ハードリンクの場合は、そのまま作成されました。

  $ ls -l /foo/bar/buz_real /foo/bar/buz_real2
  -rwxr-xr-x 2 usu  usu  340  6月 16 18:51 /foo/bar/buz_real
  -rwxr-xr-x 2 usu  usu  340  6月 16 18:51 /foo/bar/buz_real2
  $ sudo aa-autodep /foo/bar/buz_real2
  Writing updated profile for /foo/bar/buz_real2
  $ ls /etc/apparmor.d/foo*2
  foo.bar.buz_real2

そして、実体は1つのファイルですが、AppArmor 的には別ものとして処理されます。

 

次に、プログラムが扱うファイルがシンボリックリンクとハードリンクの場合どうなるか、 確認しました。

結果だけお伝えしますと、シンボリックリンクは書き込み権限さえあれば作成できます。 たとえば、/some/where にシンボリックリンクを作る権限を与えたければ、 プロファイルに以下を追記します。
(他の権限も必要なら、「rwkl」など複数指定します。以下同様。)

/some/where/*  w,

ハードリンクの場合は、 ハードリンク作成を許可するモード「l」を指定する必要があります。たとえば、 /some/where にハードリンクを作る権限を与えたければ、 プロファイルに以下を追記します。

/some/where/*  l,

デバイスファイルや名前付きパイプなどの場合はどうなるのかなど、 気になる貴兄は、ぜひ自身で確認してみてください。

今回の宿題

今回の宿題は、

  auditctlで未設定のとき、何が記録されるのか確認しましょう。

です。

デフォルトでは、特にフィルターは設定されていません。
それでは、その場合に何がログに記録されて、何が記録されないのかを、 はっきりさせておく必要があるのではないかと思います。

というわけで、次回までに調べておきましょう。

あとがき

最近、会社の影響で、ビジネススキルのなさを補う本ばかりを読んでいたのですが、 やっぱり技術なんじゃないか、と(またまた)思うようになり、 技術本をいくつか購入しています。

その中で、前から読もう読もうと思っていた本が、こちらです。

Linuxカーネル Hacks
http://www.amazon.co.jp/exec/obidos/ASIN/4873115019/usupiorg-22

ここのところ、3.0対応のカーネル本が出ていないようですが、 この本を読んで一通り確認したら、 3.0の新機能が大体肌で感じられるようになるんじゃないかな…と期待しています。

…はい、つまり、まだ全部読めていません。
最近、自転車で通勤していることと、 公共交通機関での出張がまったくと言っていいほどないため、 読書時間を確保できていません。

移動中じゃないと読まない、 といういびつな読書習慣をなんとか変えねばと思っております。

そして、なんとか読み終えたら、ここのネタが、 しばらくカーネル寄りになってしまう気が、ものすごくしています…。

 

今回も、ここまで読んでいただき、たいへんありがとうございました。
次回は、7月1日(日) の未明にお会いしましょう!

 

「いますぐ実践! Linux システム管理」の解除は、以下からできます。
http://www.usupi.org/sysad/ (まぐまぐ ID:149633)

バックナンバーは、こちらにほぼ全部そろっています。
http://www.usupi.org/sysad/backno.html

「栗日記」- 一進一退を繰り返している気がします。
http://www.usupi.org/kuri/ (まぐまぐ ID:126454)
http://usupi.seesaa.net/ (栗日記ブログ)
http://usupi.org/k/ (モバイル栗日記)


[バックナンバーのトップへ] [Linux システム管理のトップへ]

トップ

バックナンバー
    [日付順] [目的別]

プロフィール

▼ リンク

独学Linux
Linuxデスクトップ環境に関する情報が満載です。 メルマガもありますよ。
Server World
CentOS 6をサーバとしたときの設定例が、これでもかというくらいたくさん載っています。 CentOS以外のディストリビューション(Fedora, Ubuntu)も充実しています。
LINUXで自宅サーバーを構築・導入(Fedora9)
Fedora9のインストールの仕方から管理方法まで、詳しく載っています。 SearchManには情報がもりだくさんです。
マロンくん.NET
〜サーバ管理者への道〜
Linuxをサーバとして使用するための、いろいろな設定方法が載っています。 マロンくんもかわいいです。 なんといっても、マロンくんという名前がいいですね!!
日経Linux
今や数少なくなってしまったLinuxの雑誌。ニュースやガイドもあります。
Linux Square − @IT
@ITが提供する、Linux の情報が満載。 載っていない設定方法はないんじゃないでしょうか。
gihyo.jp…技術評論社
Linuxに限らず様々な技術情報が満載のサイト。 SoftwareDesign誌も、 ソフトウェア技術者は必見です。
SourceForge.JP Magazine
Linux に限らず、オープンソース関連の記事が網羅されています。
ITmediaエンタープライズ:Linux Tips 一覧
Tips というより FAQ 集でしょうか。わからないことがあれば覗きましょう。
IBM developerWorks : Linux
開発者向けですが、勉強になりますよ。
Yahoo!ニュース - Linux
Yahoo!のLinuxに関するニュース一覧です。
栗日記
システム管理とかと全然関係ありませんが、毎日栗の絵を描いています。
システム管理につかれちゃったとき、癒されたいときに、ご覧ください。:-)
WEB RANKING - PC関連
ランキングに参加してみました。押してやってください。

▼ 作ってみました

Add to Google

▼ せんでん




▼ 最近読んだ本

▼ 気に入ってる本