2017年11月19日

Linux カーネルのメモリ管理サブシステムの5つの特徴

  1. メモリ割り当て処理が先に進むことを保証しない
  2. 問題が発生する可能性があっても現実に起こるまでは対処しない
  3. 故意/悪意あるいはストレステストにより発生する問題には対処しない
  4. 自力で真犯人を逮捕できない一般人は相手にしない
  5. 他のカーネル開発者の関心を惹かない問題は解決されない

「え〜っ!?」って思われましたでしょうか?でも、そういう世界なんだということが解ってきました。

Linux 4.9 で追加されてしまった warn_alloc() によるハングアップを「故意/悪意あるいはストレステストでなくても現実に起こる問題」として削除するのに丸1年かかりました。いやはや、疲れます。

「 Linux システムがハングアップしたらメモリ管理を疑え!?」という諺は、まだ有効です。意図的なストレスを掛けることで発生する問題は全力で無視されてしまうため、実際のシステムで使われている負荷を掛けることで発生することが重要です。そのためには、利用者の皆様のご理解・ご協力が欠かせません。情報の取得方法を習得して、ハングアップを見つけたら、どんどん報告してくださいますよう、お願いいたします。

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

2017年10月24日

Apache HTTP Server 2.4.29 で修正された Out Of Memory 自爆バグについて

仕事上、例えば vmcore のような、数ギガバイトから数十ギガバイトになる可能性のある巨大なファイルを転送する必要に迫られることがあります。しかし、セキュリティ上の理由でインターネット上のサービスを利用できないという制約があるため、いっそのこと自作してしまえと思い、大容量ファイルのアップロード/ダウンロードを行うためのプログラムを試作することにしました。その際、スクリプト言語などに依存してしまうとEOLへの対応が必要になるため、10年20年先も無改造で使い続けることができるであろうC言語で、そして、メモリリークや Web サーバ本体のバージョンアップの影響を受けないようにするため、リクエスト毎に fork()/execve() する Apache のCGIとして動作するプログラムとして開発することにしました。

しかし、たまにリクエストがエラーになったり、システムの動作が極端に遅くなったりと、どうも様子がおかしいことがありました。発生条件を切り分けていったところ、何と「スリープ処理を入れずに大量のレスポンスの送信を行うだけ」で発生していることが判明しました。親プロセスである Apache のワーカープロセスが、子プロセスであるCGIプログラムの出力を全てメモリ上に保持しようとしてしまい、 OOM killer に殺されるか、さもなくば、後続のリクエストに対する fork() ができなくなるというサービス拒否状態に陥っていたのです。

おいおい、メモリ管理で悩みたくないから子プロセスを使うという選択をしたのに、親プロセスが盛大にメモリを食い潰してどうするのよ〜?

/〜(^x^)〜/

ちなみに、RHELへのバックポートは httpd-2.4.6-76.el7 に含まれる予定になっているため、 RHEL 7.5 のリリース時に修正されるものと予想しています。

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

2017年08月20日

セキュリティ・キャンプ2017で使用した、熊猫のテキストを公開しました。

昨年あたりからLSMを巡る動きが活発になってきたので、今年のセキュリティ・キャンプでは、 ウイルス対策ソフトをLSMから使うという 実習を行いました。

3年間のトラブルシューティングと、その後2年間のメモリ管理を巡る戦いにより、LSMの動向を5年間全然追いかけていなかったため、紺屋の白袴状態でした。 そのため、当初はLSMメーリングリストのアーカイブを読み直して、どのような挑戦が行われてきたのかを纏めてみるつもりでした。しかし、今年に入ってからも 「 Linux カーネルのメモリ管理機構の闇」を巡る死闘が続いており、リソースの大部分がメモリ管理機構のバグ退治に費やされてしまうという、ブラックホールから 逃げ出せない状況下での講義準備となりました。講義資料の中に OOM killer の話が何度も出てきたのは、そのせいでしょうか?(笑)

今年のキャンプでは、 DirtyCOW の件で巻き添えを喰らったり WikiPedia からブログリンク+本名暴露攻撃を喰らったりと有名ながちゃぴん先生とか、 Ryzen SEGV Battleという貴重な経験をした Sat 先生とかに会うことができて、楽しかったです。

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

2016年12月31日

Linux 4.9 が封印解除されたけれども・・・

今年はずっと「 Linux カーネルのメモリ管理機構の闇」と戦い続けてきました。

Linux カーネルのメモリ管理機構は「他の誰かが自分のために進捗を出してくれているから自分は余計なことを考えなくていい」という楽観論で動いています。そして、全員が同じ考えで動いたとき、誰も進捗を出せなくなり、システムは静かにハングアップしてしまいます。なんだか、責任の所在が不明な、某市場移転問題みたいですねぇ。

Linux 4.6 で OOM reaper が導入され、 Linux 4.9 では「 OOM killer が発動できる限りは OOM livelock 状態に陥らないことを証明できる」ようになる・・・ことを目指していました。しかし、誰も進捗を出せなくなったことを知らせてくれる仕組みとして、ストールしている間は10秒毎に警告を出力するという楽観的な修正が取り込まれたことにより、 Linux 4.8 までは存在しなかった「ロックを獲得したままバッファが空になるまで永遠に待ち続けるA v.s. ロックを獲得できないことでバッファへの追加を永遠に続けるA以外の全員」という新しい OOM livelock 状態が発生してしまいました。よって、残念ながら「 OOM livelock 状態に陥らないこと」を証明できませんでした。

この問題は printk() がバッファが空になるまで永遠に待ち続けることが原因ということにされたため、バッファを空にする処理を専用のカーネルスレッドにオフロードすることで解消される見込みです。しかし、本当の原因は「ロックを獲得したままスリープしてしまうA v.s. ロックを獲得できないままビジーループをしてしまうA以外の全員」であるため、「ロックを獲得できなかった場合はスリープすることで、ロックを獲得しているAの処理を先へと進める」というのが正しい修正だと思うのですが、そのような修正を加えることにより予期せぬ副作用が発生することを恐れているため、採用される見込みはありません。問題を指摘しても、「 DoS 攻撃を受けていて手遅れだ」という返事。原因がカーネル側にあり、それを修正する方法が存在していても、想定を超える負荷が掛かったら諦めるしかないという、セキュリティとトラブルシューティングをやっている人の視点としては納得いかない世界なのです。こんな調子では、 DirtyCOW のような脆弱性が見つかるのも、当然かもなぁ。

ストールしている間は10秒毎に警告を出力するという楽観的な修正には、全員が同じ考えで動いた場合には機能しないという致命的な欠陥があり、問題が発生しているかもしれないことを知らせるという watchdog としての役割を果たせません。この処理を、専用のカーネルスレッドにオフロードすることで、全員が同じ考えで動いてしまった場合でも機能するようにするという提案を続けています。果たして、採用されるのでしょうか?

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

2016年11月05日

セキュリティ・キャンプ2016で使用した、熊猫のテキストを公開しました。

RHEL 7.3 が封印解除されたので、自主規制を解除します。

今年のセキュリティ・キャンプでは、 Linux カーネルのメモリ管理機構の闇について扱いました。3年超の期間を費やし、3000通超の関連メールを送受信し、そして、今年1月からは会社の業務時間の大部分も使わせてもらいながら対応した、膨大な活動履歴の中から抽出したものです。

講義資料では、20年前から存在していたと考えられる脆弱性である CVE-2013-4312 および CVE-2016-2847 の発見から始まり、ずるずると闇に引き込まれていき、幾つかの問題について光を取り戻すまでを描いています。

CVE-2013-4312 および CVE-2016-2847 については RHEL 7.3 のカーネルで修正されていますので、信頼できないユーザがログインする可能性のあるシステムではカーネルをアップデートしてくださいね。先月、 DirtyCOW ( CVE-2016-5195 )への対処でカーネルをアップデートしたばかりだとは思いますが。

メモリ管理機構に起因したシステムのハングアップが発生しても、それを平均的なシステム管理者でも認知できる仕組みが存在しないため、どれくらいの頻度で発生しているのかについての情報はありません。サポートセンタに「今回のハングアップに関して、メモリ管理機構が原因の可能性はあるか?」と照会しても、「判断できない」としか答えられないのです。もし、「無い」とか「低い」とか回答するようなサポートセンタを見つけたら、この資料を見せてやってくださいな。(笑)

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

2016年10月05日

CaitSith 0.1.17 / 0.2 が公開されました。

熊猫にとって今年最大のイベントであるセキュリティ・キャンプ全国大会2016と会社のインターンシップ期間が終わり、 Linux 4.8 もリリースされたことで、ようやく肩の荷が下りました。そのため、 CaitSith をメインライン化するための活動を開始しました。

https://ja.osdn.net/projects/tomoyo/lists/archive/users/2016-September/001008.html
https://ja.osdn.net/projects/tomoyo/lists/archive/users/2016-October/001009.html

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

2015年12月25日

TOMOYO Linux 1.8.5 / AKARI 1.0.35 が公開されました。

公開されたのは10周年記念である2015年11月11日です。

今年はずっとOOM killer との死闘を繰り広げていました。
簡単にまとめると、

  1. Linux カーネルのメモリアロケータは経験則に基づくヒューリスティックの塊。
  2. そのため、カーネル開発者が想定していなかった負荷が掛かった場合、 OOM killer が発動しないまま無限ループに陥る状況が簡単に発生する。
  3. つまり、 OOM killer が発動できたら、それはラッキーである証拠。 OOM killer が発動できなかったら、諦めるしかない。
  4. そして、無限ループに陥っている可能性を知らせる機能は存在しない。そのため、何が発生しているのかを観測できず、メモリ管理に起因した問題として修正することもできない。
  5. その結果、「システムがハングアップしたらメモリ管理を疑え!?」という諺が誕生しても不思議ではない。
  6. Linux 4.6 に向けて、 OOM 状態の検知と OOM killer の改善に本腰を入れようとしている。しかし、バックポートについては全然考慮されていないため、既存システムへの適用は絶望的である。

という状況です。 Linux の利用者も、トラブル対応を行うサポートセンタの人たちも、解けないパズルで悩むことが無いように、 RHEL 7.2 のリリースまでに決着をつけたかったのですが、来年へと持ち越しとなりました。

posted by 熊猫さくら at 20:25| Comment(0) | TrackBack(0) | TOMOYO Linux

2015年12月21日

環境変数 TZ の謎

とあるプログラムのパフォーマンス測定をしていたら、 localtime() 関数の処理で予想外に時間がかかっていることが判明しました。

そこで、 localtime() 、 localtime_r() 、 gmtime() の3つについて、どれくらいの時間がかかっているのかを簡単に計測してみました。

$ gcc -Wall -O3 -x c - << "EOF"
#include <stdio.h>
#include <time.h>

int main(int argc, char *argv[])
{
        int i;
        time_t now = time(NULL);
        struct tm tm0 = { };
        struct tm *tm;
        if (argc == 3)
                for (i = 0; i < 100000000; i++)
                        tm = gmtime(&now);
        else if (argc == 2)
                for (i = 0; i < 100000000; i++)
                        tm = localtime_r(&now, &tm0);
        else
                for (i = 0; i < 100000000; i++)
                        tm = localtime(&now);
        printf("%04u/%02u/%02u %02u:%02u:%02u\n",
               tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday, tm->tm_hour,
               tm->tm_min, tm->tm_sec);
        return 0;
}
EOF

localtime()localtime_r()gmtime()
$ time ./a.out$ time ./a.out 1$ time ./a.out 1 2

仮想化環境での簡単な計測なのであまり正確ではありませんが、確実に localtime() 関数は gmtime() 関数と比べて遅いようです。

localtime()localtime_r()gmtime()
real 2m6.615s
user 0m51.170s
sys 1m15.550s
real 0m38.278s
user 0m38.309s
sys 0m0.000s
real 0m3.995s
user 0m3.994s
sys 0m0.002s

この原因は、 localtime() 関数は呼び出しの度に、 /etc/localtime の内容が変化していないかどうかを確認するために stat() システムコールを発行しているためです。

CentOS 7 では /etc/localtime が ../usr/share/zoneinfo/Asia/Tokyo へのシンボリックリンクとなっているため、 stat() システムコールでの無駄を減らすために、 /etc/localtime を /usr/share/zoneinfo/Asia/Tokyo のコピーに置き換えて実験してみました。シンボリックリンクを辿らないで済む効果はあるようです。

localtime()localtime_r()gmtime()
real 1m22.785s
user 0m52.446s
sys 0m30.407s
real 0m37.940s
user 0m37.970s
sys 0m0.000s
real 0m3.951s
user 0m3.954s
sys 0m0.000s

次に、環境変数 TZ で zoneinfo ファイルの場所を指定( export TZ=:Asia/Tokyo )して実験してみました。すると、 stat() システムコールが発行されなくなくなった分、 localtime() 関数が速くなりました。

localtime()localtime_r()gmtime()
real 0m39.887s
user 0m39.919s
sys 0m0.002s
real 0m37.597s
user 0m37.629s
sys 0m0.000s
real 0m3.970s
user 0m3.971s
sys 0m0.002s

次に、環境変数 TZ でタイムゾーン情報を指定( export TZ=JST-9 )して実験してみました。すると、 localtime_r() 関数が gmtime() 関数と同じレベルまで速くなりました。

localtime()localtime_r()gmtime()
real 0m8.735s
user 0m8.740s
sys 0m0.003s
real 0m6.733s
user 0m6.738s
sys 0m0.000s
real 0m6.647s
user 0m6.651s
sys 0m0.001s

でも、ちょっと不思議なことが起きてますよね?何故か、 gmtime() 関数は環境変数 TZ にタイムゾーン情報が指定されていると遅くなってしまうようです。

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

2015年12月15日

SECCON 2015 オンライン CTF での Command-Line Quiz について

telnet でログインしたらシェルが与えられるのに、自由にファイルを読むことができない不思議なシェル環境、あの問題は CaitSith の機能を用いて実現しました。

CaitSith login: root
Password:
$ id
uid=10000 gid=10000 groups=10000
$ ls -l
drwxr-xr-x    2 root     0            1880 Dec  5 05:18 bin
drwxr-xr-x    3 root     0             180 Dec  5 05:02 dev
drwxr-xr-x    2 root     0             100 Dec  5 05:02 etc
-rw-r--r--    1 600      0              87 Dec  5 04:48 flags.txt
-rwx------    1 root     0           13750 Dec  5 05:01 init
drwxr-xr-x    2 root     0              80 Dec  5 05:02 lib
-rwxr-xr-x  313 root     0          831112 Feb 19  2015 linuxrc
dr-xr-xr-x   73 root     0               0 Dec  5 05:18 proc
drwxr-xr-x    2 root     0            1180 Dec  5 05:18 sbin
-rw-r--r--    1 100      0             262 Dec  5 04:48 stage1.txt
-rw-r--r--    1 200      0             265 Dec  5 04:48 stage2.txt
-rw-r--r--    1 300      0             270 Dec  5 04:48 stage3.txt
-rw-r--r--    1 400      0             247 Dec  5 04:48 stage4.txt
-rw-r--r--    1 500      0             280 Dec  5 04:48 stage5.txt
drwxrwxrwt    2 10000    10000          60 Dec 15 13:57 tmp
drwxr-xr-x    4 root     0              80 Dec  5 05:02 usr
$ cat *.txt
cat: can't open 'flags.txt': Operation not permitted
What command do you use when you want to read only top lines of a text file?

Set your answer to environment variable named stage1 and execute a shell.

  $ stage1=$your_answer_here sh

If your answer is what I meant, you will be able to access stage2.txt file.
cat: can't open 'stage2.txt': Operation not permitted
cat: can't open 'stage3.txt': Operation not permitted
cat: can't open 'stage4.txt': Operation not permitted
cat: can't open 'stage5.txt': Operation not permitted
$ stage1=head sh
$ cat *.txt
cat: can't open 'flags.txt': Operation not permitted
cat: can't open 'stage1.txt': Operation not permitted
What command do you use when you want to read only bottom lines of a text file?

Set your answer to environment variable named stage2 and execute a shell.

  $ stage2=$your_answer_here sh

If your answer is what I meant, you will be able to access stage3.txt file.
cat: can't open 'stage3.txt': Operation not permitted
cat: can't open 'stage4.txt': Operation not permitted
cat: can't open 'stage5.txt': Operation not permitted
$ stage2=tail sh
$ cat *.txt
cat: can't open 'flags.txt': Operation not permitted
cat: can't open 'stage1.txt': Operation not permitted
cat: can't open 'stage2.txt': Operation not permitted
What command do you use when you want to pick up lines that match specific patterns?

Set your answer to environment variable named stage3 and execute a shell.

  $ stage3=$your_answer_here sh

If your answer is what I meant, you will be able to access stage4.txt file.
cat: can't open 'stage4.txt': Operation not permitted
cat: can't open 'stage5.txt': Operation not permitted
$ stage3=grep sh
$ cat *.txt
cat: can't open 'flags.txt': Operation not permitted
cat: can't open 'stage1.txt': Operation not permitted
cat: can't open 'stage2.txt': Operation not permitted
cat: can't open 'stage3.txt': Operation not permitted
What command do you use when you want to process a text file?

Set your answer to environment variable named stage4 and execute a shell.

  $ stage4=$your_answer_here sh

If your answer is what I meant, you will be able to access stage5.txt file.
cat: can't open 'stage5.txt': Operation not permitted
$ stage4=awk sh
$ cat *.txt
cat: can't open 'flags.txt': Operation not permitted
cat: can't open 'stage1.txt': Operation not permitted
cat: can't open 'stage2.txt': Operation not permitted
cat: can't open 'stage3.txt': Operation not permitted
cat: can't open 'stage4.txt': Operation not permitted
OK. You reached the final stage. The flag word is in flags.txt file.

flags.txt can be read by only one specific program which is available
in this server. The program for reading flags.txt is one of commands
you can use for processing a text file. Please find it. Good luck. ;-)
$ sed "" flags.txt
OK. You have read all .txt files. The flag word is shown below.

SECCON{CaitSith@AQUA}
$

シェルを起動するたびに読めるファイルが変化したり、環境変数の内容に応じてアクセスの可否が決まったりというのは、 TOMOYO / AKARI / CaitSith ならではのアクセス制限です。どのようなルールを使っていたのかを、ここで紹介します。

POLICY_VERSION=20120401

10 acl execute task.uid!=0 task.domain="<kernel>"
    10 allow transition="stage1"
    20 deny

10 acl execute task.domain="stage1"
    10 allow envp["stage1"]="head" transition="stage2"
    20 allow

10 acl execute task.domain="stage2"
    10 allow envp["stage2"]="tail" transition="stage3"
    20 allow

10 acl execute task.domain="stage3"
    10 allow envp["stage3"]="grep" transition="stage4"
    20 allow

10 acl execute task.domain="stage4"
    10 allow envp["stage4"]="awk" transition="stage5"
    20 allow

10 acl read path.uid=100
    10 allow task.domain="stage1"
    20 deny

10 acl read path.uid=200
    10 allow task.domain="stage2"
    20 deny

10 acl read path.uid=300
    10 allow task.domain="stage3"
    20 deny

10 acl read path.uid=400
    10 allow task.domain="stage4"
    20 deny

10 acl read path.uid=500
    10 allow task.domain="stage5"
    20 deny

10 acl read path.uid=600
    10 allow task.exe="/bin/sed" task.domain="stage5"
    20 deny

10 acl inet_stream_connect task.uid!=0
    10 deny

10 acl inet_stream_listen
    10 allow port=23
    20 deny

10 acl inet_dgram_send task.uid!=0
    10 allow port=53 ip=133.242.0.3
    10 allow port=53 ip=133.242.0.4
    20 deny

最初の規則は、一般ユーザ(UIDが0ではないプロセス)かつドメインが <kernel> であるプロセスからプログラムが実行された場合、 stage1 ドメインへ遷移するという指定です。これは、 root ユーザとしてログイン後、ログインシェルから一般ユーザのユーザIDが割り当てられて、シェルが開始されることにより stage1 ドメインに遷移するという動作に対応します。

次の規則は、ドメインが stage1 であるプロセスからプログラムが実行された場合、環境変数 stage1 の値が head であれば stage2 ドメインに遷移し、それ以外の場合には、ドメインを遷移せずにプログラムを実行するという指定です。これは、 stage1.txt の回答が head であれば stage2 へ進むことができ、そうでなければ stage2 へは進めないという動作に対応します。普通のアクセス制御では許可する場合を列挙したら残りは全て拒否するものですが、ここでは意図的に全てを許可するように指定しています。これにより、正解でも不正解でもシェルが実行できるため、総当たり攻撃による突破を困難にしています。

以下同様に、ドメインが stage2 であるプロセスからプログラムが実行された場合、環境変数 stage2 の値が tail であれば stage3 ドメインに遷移、ドメインが stage3 であるプロセスからプログラムが実行された場合、環境変数 stage3 の値が grep であれば stage4 ドメインに遷移、ドメインが stage4 であるプロセスからプログラムが実行された場合、環境変数 stage4 の値が awk であれば stage5 ドメインに遷移するという指定を行っています。

次に、それぞれのドメインでどのファイルを読めるかについての指定を行います。パス名ベースのアクセス制御の弱点である、パス名が変化するとアクセスの可否も変化してしまうという問題を回避するため、ファイルの所有者IDをキーとして許可を与えるようにしています。この方法なら、細かくリネームやハードリンクなどの作成を制限する必要がありません。パス名以外をキーに指定できる CaitSith の利点が生かせる指定です。

具体的には、所有者IDが100のファイルは、ドメインが stage1 であるプロセスからのみ読み出すことができるという指定を行っています。以下同様に、所有者IDが200のファイルはドメインが stage2 であるプロセスからのみ、所有者IDが300のファイルはドメインが stage3 であるプロセスからのみ、所有者IDが400のファイルはドメインが stage4 であるプロセスからのみ、所有者IDが500のファイルはドメインが stage5 であるプロセスからのみ読み出すことができるという指定を行っています。これらは、それぞれのステージで stage1.txt から stage5.txt までの何れか1個だけを読み出すことができるという動作に対応します。

所有者IDが600である flags.txt を読み出す許可だけは、少し異なる方法で指定しています。具体的には、プロセスのドメインが stage5 で、かつ、実行中のプログラムのパス名が /bin/sed である場合のみ読み出すことができるという指定を行っています。

その他、他のサーバへの攻撃に使われないようにするために、ネットワークの制限も行っています。具体的には、ユーザIDが0ではないプロセスは外向きのTCP接続を全面的に禁止しています。また、内向きのTCP接続はポート23のみを許可しています。ユーザIDが0ではないプロセスは、外向きのUDP接続として、DNSサーバである 133.242.0.3 および 133.242.0.4 のポート53のみを許可しています。

以上が、今回の出題で使われたルールです。もっと複雑なルールを指定することもできますが、エスパー問題化を回避するために、簡単なルールを指定しながら、ヒントも与えるようにしています。ヒントを削ってしまうと、攻略不可能なケロちゃんチェック問題になってしまいますからねぇ。

勝手にQ&A:

  • 何故 root ユーザでログインしているのにシェルのプロンプトが一般ユーザ用なの?→他の挑戦者への妨害を防ぐために、セッション毎に異なるユーザIDや /tmp ディレクトリを割り当てていたためです。

  • シェルログインさせておいて、スパムメールの発射台にされないの?→上述した通り、ネットワーク制限が掛かっているので発射台にはできないでしょう。

  • ハードディスクが見つからなかったのですが?→すべてオンメモリで動作しています。 initramfs 内の busybox により一通りの機能は提供されていました。そのため、 /init と、セッション隔離を行うためのログインシェルである /bin/loginshell 、それらが依存している ld-linux.so.2 と libc.so.6 だけを initramfs に追加し、 CaitSith のポリシーも含めて全て vmlinuz 内に埋め込みました。 vmlinuz ファイル1個だけで動作するので、 PXE で使うのも簡単です。

  • vmlinuz ファイル1個だけで動作する Linux 環境ってどうやって作るの?→今年のセキュリティ・キャンプの事前学習資料で扱っています。この資料で説明されている内容を参考に、NICドライバなど幾つかの機能を追加すればネットワーク接続もできるカーネルができあがります。

  • 何故 ssh ログインじゃないの?→準備時間が足りませんでした。(笑)

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

2015年08月18日

セキュリティ・キャンプ2015で使用した、熊猫のテキストを公開しました。

去年から今年にかけて、例えば Shell Shock 脆弱性のような、OSレイヤーでの重大な脆弱性が見つかり、セキュリティ意識の高い人たちの間では「 SELinux を使おうよ」という機運が高まっているのかもしれません。しかし、サポートセンターでの経験より、「 SELinux を使ってトラブルが起きても対処できない」という人たちも大勢いることが判りました。そこで、改めて「OSの挙動を知って、OSレイヤーのセキュリティについて考えてみよう」と思い、今年度は「 TOMOYO / AKARI / CaitSith ハンズオン」というテーマにしました。

読むためのPDF版コピペするためのテキスト版

今回のテキストは、事前学習資料部分と当日学習資料部分の2部構成になっています。

事前学習資料部分では、「講義で使う環境に慣れてもらう」ことを意図して、「 PXE ブートして sl コマンドが走る Linux 環境を作る」ことに挑戦していただきました。 Scientific Linux ならぬ、 SL Linux です。(これは、昨年度のキャンプの企業見学からの帰りのバスの中での雑談から思いついたネタです。)

当日学習資料部分では、 TOMOYO をメインライン化するまでのドタバタ劇とか、3年間 RHEL システムのトラブルシューティング業務に従事して痛感した組織の問題点とかのような、技術的に Linux システムに詳しくない人にも何かの役に立つ話を交えたいと思いました。また、緊急コラム「 bash 脆弱性( CVE-2014-6271 )の影響範囲の調査方法について」が掲載されました。で「あまりに dis りすぎたため、公開したら怒られそうな内容になってしまいました」と書いたように、一昨年/昨年のテキストについては公開することを躊躇っていましたが、責任をとらないお偉いさんたちが蔓延していく現在の日本の危機的状況を見て、「来年では間に合わない」と判断し、過去テキストも含めて全テキストへのリンクを含めることにしました。

当日学習で使用した VirtualBox 向けのVMイメージは、 http://jaist.dl.sourceforge.jp/caitsith/63583/ からダウンロードできます。(ただし、サイズが大きいので、1か月後くらいに削除するつもりです。テキストでは CentOS 6 / CentOS 7 / Ubuntu 14.04 の3つしか言及していませんが、受講者の中に Arch Linux ユーザが居ましたので、 Arch Linux 用のVMイメージも用意しました。)

キャンプの様子は http://togetter.com/li/859151 から察していただければと思います。他の講師の方々が公開された資料や、参加者の反応なども見つけることができます。

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