Linux カーネルのメモリ管理サブシステムの５つの特徴
メモリ割り当て処理が先に進むことを保証しない 問題が発生する可能性があっても現実に起こるまでは対処しない 故意／悪意あるいはストレステストにより発生する問題には対処しない 自力で真犯人を逮捕できない一般人は相手にしない 他のカーネル開発者の関心を惹かない問題は解決されない 「え～っ！？」って思われましたでしょうか？でも、そういう世界なんだということが解ってきました。 Linux 4.9 で追加されてしまった warn_alloc() によるハングアップを「故意／悪意あるいはストレステストでなくても現実に起こる問題」として削除するのに丸１年かかりました。いやはや、疲れます。 「 Linux システムがハングアップしたらメモリ管理を疑え！？」という諺は、まだ有効です。意図的なストレスを掛けることで発生する問題は全力で無視されてしまうため、実際のシステムで使われている負荷を掛けることで発生するこ
Linux 4.9 が封印解除されたけれども・・・
今年はずっと「 Linux カーネルのメモリ管理機構の闇」と戦い続けてきました。 Linux カーネルのメモリ管理機構は「他の誰かが自分のために進捗を出してくれているから自分は余計なことを考えなくていい」という楽観論で動いています。そして、全員が同じ考えで動いたとき、誰も進捗を出せなくなり、システムは静かにハングアップしてしまいます。なんだか、責任の所在が不明な、某市場移転問題みたいですねぇ。 Linux 4.6 で OOM reaper が導入され、 Linux 4.9 では「 OOM killer が発動できる限りは OOM livelock 状態に陥らないことを証明できる」ようになる・・・ことを目指していました。しかし、誰も進捗を出せなくなったことを知らせてくれる仕組みとして、ストールしている間は１０秒毎に警告を出力するという楽観的な修正が取り込まれたことにより、 Linux 4.8
セキュリティ・キャンプ２０１５で使用した、熊猫のテキストを公開しました。
去年から今年にかけて、例えば Shell Shock 脆弱性のような、ＯＳレイヤーでの重大な脆弱性が見つかり、セキュリティ意識の高い人たちの間では「 SELinux を使おうよ」という機運が高まっているのかもしれません。しかし、サポートセンターでの経験より、「 SELinux を使ってトラブルが起きても対処できない」という人たちも大勢いることが判りました。そこで、改めて「ＯＳの挙動を知って、ＯＳレイヤーのセキュリティについて考えてみよう」と思い、今年度は「 TOMOYO / AKARI / CaitSith ハンズオン」というテーマにしました。 読むためのＰＤＦ版／コピペするためのテキスト版 今回のテキストは、事前学習資料部分と当日学習資料部分の２部構成になっています。 事前学習資料部分では、「講義で使う環境に慣れてもらう」ことを意図して、「 PXE ブートして sl コマンドが走る Li
第１６回「 kernel-debug ノススメ」が掲載されました。
今回は デバッグ用カーネルの紹介です。でも、デバッグ用カーネルの紹介だけで１話持たせるのは無理があるので、過負荷試験の話も入れました。 今までは「システムがダウンするくらいにまでメモリ負荷を掛けたら、いつ回復するか予測できないストール状態に陥るのは当然だ。そのような負荷を掛けたユーザのほうが悪い」と相手にされなかったのですが、実は「無限ループに陥るトドメの一撃」を喰らわせていたのはユーザ側ではなくメモリ管理機構側だったようです。 前回紹介したメモリ枯渇時の挙動についての議論が、 3.19-rc6 後に紛れ込んだ予期せぬ挙動の変化をきっかけに、一気に動き出しました。 ext4 でファイルシステムエラーが頻発したり、 xfs でページフォールトするだけで OOM killer が発生したりと、全く使い物にならなくなってしまうことが確認されたため、とりあえずは元の挙動に戻されました。 そして、
第９回「アップデートノススメ」が掲載されました。
今回は RHEL におけるソフトウェアの管理の話です。 この連載のタイトルは「ヤマノススメ」に倣っているので、企画段階では今回は rpm パッケージを管理するための yum コマンドの使い方を紹介する「 yum ノススメ」となる予定でした。 しかし、今年も大型脆弱性が続々と発見されているのに、相変わらず「アップデートしないで済む根拠」を確認するための問合せが目立っており、どうも「アップデートすることを必要以上に恐れすぎているのではないか」と思えるのです。「リグレッションに遭遇して動かなくなるのが怖い」のか「個々のプログラムや設定がどこでどのように影響しあっているかを知らないから怖い」のかは判りません。前者なら変更履歴とソースコードとの照合を行うとか、後者なら自分が管理しているシステムについて理解しようと努力するとか、塩漬けにする以外に何かできることはあると思います。オープンソースを使ったシ
Microsoft Office から PDF 形式で保存する場合に注意すること
Office 2007 にはプライバシー情報を削除する機能が搭載されていますが、公開用に PDF 形式で保存する場合、その機能を利用しても埋め込みオブジェクトのパス名など削除されない情報があります。 PDF 形式で保存する（ http://www.atmarkit.co.jp/fwin2k/win2ktips/908offpdf/offpdf.html ）際に、ファイル名を指定するダイアログに表示されている「オプション」ページを開き、「アクセシビリティ用のドキュメント構造タグ」チェックを外すと削除されるようです。 なんというか、「攻撃者のためのアクセシビリティ用のドキュメント構造タグ」あるいは「情報漏えい促進のためのドキュメント構造タグ」と呼んだ方が正確かも？ http://forums.adobe.com/thread/405476
「セキュリティ＆プログラミングキャンプ２０１１」（無償）／「 TOMOYO Linux（セキュアＯＳ）適用技術」（有償）のお知らせ
どういう訳か、８月に開催されるセキュリティ＆プログラミングキャンプ２０１１の「セキュアなＯＳを作ろうクラス」で講師をさせていただくことになりました。 TOMOYO の考え方や TOMOYO にまつわる苦労話とかが中心になるのかな？講師経験が無く、人前に出るのが苦手な熊猫さくらに務まるものなのかドキドキしています。何をどう話すかの参考にするための過去の教材とか無いかなぁ？ ９月には高度ポリテクセンターでの有償セミナーがあります。こちらは TOMOYO の使い方を習得することが中心です。 どちらも受講者を募集中だそうです。ＯＳレベルのセキュリティというと目立たなすぎて、なかなか受講者が集まらないんですよねぇ・・・。
お遊び： gzip ファイルのハッシュ値を選ぶ
以前、お遊び： tar ball のハッシュ値を選ぶでファイルを作成した時刻により md5sum の値が変化するというのを紹介しましたが、調査の結果、 gzip ファイルのヘッダ部分に埋め込まれている MTIME 部分が変化していることが原因であることが判明しました。 ということで、この MTIME 部分の値を書き換えれば、好きな md5sum 値を簡単に取得できるわけです。 TOMOYO Linux の tarball は、「配布用かテスト用か」および「最後までダウンロードされたかどうか」を簡単に見分けられるようにするために、以下のようなプログラムを用いて md5sum 値の先頭４桁が同じになるように選んでいます。（熊猫が作成した tarball かどうかの確認には、ファイル名の末尾に .asc を付与したファイルもダウンロードして、 gpg で確認してください。） /* gcc thi
AKARI 1.0.10 が公開されました。
「社長が現れて無限ループから救い出してくれた」でこちらへ来られた方へ：元ネタを知りたい場合は AQUA 第１巻の第４話 「猫の王国」をご覧ください。・・・最初は頭の中でぐるぐる回るほうの無限ループかと思って、まぁ社長が悩めるアリスちゃんを救う話ってどんなんだったっけ？と考えてしまいました。（笑） ということで（？）本文。 カーネル 2.6.23 以前および 2.6.30 以降において、一部のインタプリタ（例えば /lib/ld-linux.so.2 ）のパーミッションがチェックされていなかったのを修正しました。 TOMOYO 2.x および AKARI では全てのインタプリタのパーミッションが security_bprm_check() でチェックされているものと思っていました。しかし、実際には open_exec() を呼び出すハンドラの内、一部しか search_binary_hand
AKARI プロジェクト始めました。
AKARI は Linux 2.6 カーネル向けのアクセス解析／制限モジュールです。 TOMOYO Linux の作者である熊猫さくらが個人で勝手に開発して公開しているものであり、ＮＴＴデータとして承認されたものではありませんのでご注意ください。 TOMOYO Linux を使うのに、 TOMOYO 1.x は機能は多いけれどカーネル本体を置き換えなければいけないので敷居が高い、 TOMOYO 2.x はディストリビュータがサポートしてくれていれば簡単に導入できるけれども RHEL では SELinux しかサポートされていないのでやっぱり敷居が高い、という問題がありました。 Linux カーネル 2.6 のＬＳＭ（ Linux Security Modules ）はＬＫＭ（ Loadable Kernel Modules ）からはアクセスできないと信じられてきましたが、実際にはＬＫＭから
TOMOYO Linux 1.6.8 が公開されました。
http://sourceforge.jp/projects/tomoyo/lists/archive/users/2009-May/000602.html パス名ベースのアクセス制御とラベルベースのアクセス制御との論争を通じて、パス名ベースのアクセス制御でないと実現できないセキュリティも存在することが明らかになったことと思います。 既存ファイルの読み書き実行の可否を制限する上ではパス名ベースよりもラベルベースの方が上手に制限することができます。しかし、セキュリティは読み書き実行の可否だけで決まるものではありません。どのように使われるか（どのように振る舞うか）を考慮することもセキュリティの一部です。ファイルの名前が変化すると、どのように使われるかも変化します。そして、ファイルの名前の変化を制限する上では、ラベルベースよりもパス名ベースの方が上手に制限することができます。 Ｗｅｂサーバで考え
TOMOYO Linux 2.2.0 を含んだ Linux カーネル 2.6.30-rc1 がリリースされました。
一時期「 Web 2.0 」なんていう言葉が流行ったようですが、その後も Web アプリケーションに関するセキュリティ問題は尽きませんねぇ。 熊猫さくらは、最初からこうなることをスラドで予想していました。 そもそも、ＨＴＭＬという「指示された通りに動く言語」を使っているから振り込め詐欺に騙される隙を与えてしまうのであって、ＨＴＭＬを使わないようにすれば Web システムのユーザが被害にあう原因の多くを解消できるはずです。 「帳票入力アプリケーションの見直しについて」では、ｓｓｈプロトコルを使うことを提案しました。まぁ、ファイアウォールの設定によりｓｓｈプロトコルを利用できないからｈｔｔｐプロトコルを渋々使っているという場合もあるでしょう。でも、ｈｔｔｐプロトコルを使ってＨＴＭＬ形式以外のデータをやり取りしてはいけないという規則はありません。 「ブラウザ」という「接続相手に指示された通りに動
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CaitSith プロジェクト始めました。
TOMOYO Linux 2.2.0 が Linus's git tree にマージされました。