2014年09月30日

緊急コラム「 bash 脆弱性( CVE-2014-6271 )の影響範囲の調査方法について」が掲載されました。

デング熱で騒いでいたと思った世の中が、突然 bash 脆弱性とか御嶽山噴火とかで騒ぎ出しました。今回の bash 脆弱性は、まさに TOMOYO とか AKARI とか CaitSith とかが活躍するケースな訳ですが、 Red Hat 社のサポート対象外な機能であるため、商用サポートを必要とするお客様に紹介することができず、焦りと残念さが募っています。

でも、せっかく連載をしているところですので、思い切って緊急コラムとして掲載しちゃいました。(即日で作成したので詳細までは準備できませんでした。質問などがありましたら遠慮なくどうぞ。)

熊猫がセキュリティキャンプに参加するようになってから今年で4回目になる訳ですが、年々技術的なトピックから離れてきているのを感じています。それは、OSレベルのアクセス制御に興味を持ってくれる人が少ないからという理由もあります。しかし、「プログラムのアイデア出しから保守まで全部を自分で行う」側から「他人が作成したプログラムの不具合調査を行う」側になったことで、「誰かが面倒を見てくれている筈だから、自分は考えなくてよい」という「隅々から全体までを通して見ようとしない」姿勢こそが問題の根底にあるのではないかと思うようになったからという理由もあります。なので、今年のキャンプでは、熊猫が感じている現在のSI業界の問題点を取り上げ、

「自分に関係しないことは気にしない」では済まされない。
システムのトラブル/セキュリティの脅威は、助け合いなしでは対処できない。

という話を含めました。あまりに dis りすぎたため、公開したら怒られそうな内容になってしまいましたが、まさに今回の脆弱性のような「事件」への対応姿勢がそれを問うているように思えます。

posted by 熊猫さくら at 21:29| Comment(0) | TrackBack(0) | Linux

第5回「 SysRq ノススメ」が掲載されました。

今回は SysRq の紹介です。

全プロセスのバックトレースを取得する方法として SysRq-t と kdump とがあり、 SysRq-t には以下のような利点があります。

  • 動作中のマシンをクラッシュさせることなく情報を取得できる
  • 時間経過に伴い処理が先に進んでいるかどうか(バックトレース内容が変化しているかどうか)を確認できる
  • それに対して、 kdump には以下のような利点があります。

  • バックトレース内にゴミが混入しないので内容を把握しやすい
  • (時間経過を伴わないため)一貫性のある結果が得られる
  • バックトレース以外にも様々な状態を確認できる
  • そのため、より確実な情報取得のためにマシンをクラッシュさせることが許されるのであれば、何回か SysRq-t を実行した後に、 SysRq-c を実行して kdump を取得するというのが好ましいと考えます。

    ちなみに、 libvirt 経由で KVM ゲストを稼働させている場合、 virsh dump コマンドを実行することで「動作中のマシンをクラッシュさせることなく kdump 相当の情報を取得できる」ので、 SysRq-t と kdump の両方の利点を得ることができます。 KVM ホストへのシェルログインを許可していないクラウドサービスでも、故障解析情報取得用に Web CGI インタフェースを使って virsh dump 機能を提供してもらえないものかなぁ?

    posted by 熊猫さくら at 21:27| Comment(0) | TrackBack(0) | Linux

    2014年09月16日

    第4回「 udplogger ノススメ」が掲載されました。

    今回は udplogger の紹介です。前回紹介した netconsole の受信側プログラムとしてはもちろんのこと、情報取得のために仕掛けた SystemTap の出力メッセージを受信させたり、ローカルディスクへの書き込みが遅延する恐れがある場合に数秒間隔で取得している性能データを他のホスト上に保存させたりするという使い方もできます。

    「ローカルディスクへの書き込みが遅れるなんてことあるんかいな?」と思われるかもしれませんが、実際に遅延した事例があります。 rsyslog のデフォルト設定では書き込みの完了を待つようになっているため、 Serial ATA の Native Command Queuing 機能により、業務アプリケーションによる大量のディスク I/O が優先されてしまい、死活監視で使っている /bin/su を実行した際の /var/log/secure への記録が大幅に遅延して、死活監視のタイムアウトエラーが発生してしまいました。結局、 /var/log/secure への書き込みの完了を待たないように rsyslog の設定を変更して対処しました。

    「ヤマノススメ」は風景描写が丁寧ですねぇ。「ARIA」を思い出します。 そういえば、アニメで口笛シーンが登場するのは珍しいことかも。

    posted by 熊猫さくら at 23:14| Comment(0) | TrackBack(0) | Linux

    2014年09月02日

    第3回「 netconsole ノススメ」が掲載されました。

    今回は netconsole の紹介です。 VMware や KVM などの仮想化環境の普及に伴い、ホスト側でのハードウェア増設/設定の変更/ログファイルへのアクセスが不可能という制約を持つ環境が増えてきたので、 netconsole が活躍してくれることを期待しています。

    しかし、 netconsole で難しいのは、送信側よりも受信側なのかもしれません。というのも、 netconsole のメッセージを受信しようと真面目に考えられた RHEL 同梱の(言い換えると Red Hat 社のサポート対象である)パッケージが見当たらない( https://access.redhat.com/solutions/4258 では rsyslog を紹介しているものの、 https://bugzilla.redhat.com/show_bug.cgi?id=432160 にあるようにそのままでは使い物にならない。 https://openvz.org/Remote_console_setup#Netconsole にあるように %rawmsg% を使えばとりあえず受信はできるものの、送信元やタイムスタンプの情報も一緒に記録してくれないと不便。かといって、 %fromhost-ip% と %timegenerated% と %rawmsg% とを同時に指定すると、必要以上にログファイルを肥大化させてしまうし、余分な送信元やタイムスタンプを除去してからでないと読めないというのも面倒。)ので、 udplogger を作成しました。それでも、どうしても rsyslog を使わなければいけないのであれば、 $EscapeControlCharactersOnReceive や $DropTrailingLFOnReception という指定が通常の syslog メッセージに干渉するのを防ぐために、 netconsole 専用の rsyslogd インスタンスを起動した方が良いと思います。その際、 -x オプションを忘れると、 netconsole から送信されたカーネルメッセージに含まれている文字列をホスト名だと勘違いして手当たり次第DNS問合せをしてしまいますのでご注意を。

    ♪なつい〜ろ〜プ〜レゼント〜」に「なんのこっちゃ?」と思った方へ:この連載の各話のタイトルは「ヤマノススメ セカンドシーズン」という現在放送中のアニメに倣っています。そして、「夏色プレゼント」というのは、そのアニメのオープニング曲です。前回の記事で「侵略!イカ娘」じゃないよと熊猫が書いたことに対して正解を示唆してくれているものと思われます。

    今年もセキュリティキャンプ2014が開催された訳ですが、2014年度の第1Qには「ふんわり」系のアニメがたくさん放送されていたのを反映してか、いろいろなアニメネタが登場しました。「ごちうさ」の「ぴょんぴょん」とか(由来は知らないけれど)「ておくれポイント」とかが健闘しましたが、最も猛威を振るったのは「進捗どうですか?」かと思われます。流行はしなかったけれども大爆笑したのは、「一週間フレンズ。」を捩った「進捗フレンズ。」ですねぇ。

    2014年度の第2Qは、あまり「ふんわり」系のアニメが見当たらず、ちょっと寂しいです。そんな中、「ヤマノススメ」はゆるふわキャラクターによる山登りの話だと思っていたのに、なぜか温泉の話、スカートの話、水着の話と山じゃない話が続いていてドキドキ。(笑)いや、ゆるふわでも真面目なアニメなので問題描写は登場しない筈。

    posted by 熊猫さくら at 21:36| Comment(0) | TrackBack(0) | Linux