今年も金沢ミニキャンプでTomoriNaoシールを配りました。
これは 友利奈緒 Advent Calendar 2017 3日目の記事です。
セキュリティ・ミニキャンプ in 北陸 2017(金沢)に焼きとうもろこし担当で参加しました。 今年も天候が良かったです。残念ながらグリルは用意されていませんでした。
今年はWebとカーネルの脆弱性にフォーカスした内容でした。チョイスが極端っすね。
『Chrome拡張機能の脆弱性を探そう』
影白 さんの講義。XSS脆弱性があるChromeの拡張機能がどのような問題を起こすのかを検証しました。WebサイトのXSS脆弱性は知っているという人には新しい観点を与えられる点でいい講義でした。HTMLとjQueryを知らない人には手に負えない厳しい内容でした。要改善っすね。
昼食
金沢らしいお弁当が出てきました。カリフォルニアロールらしきものが一番美味しかったっす。
みんなが食べ終わった頃に、一人ひとりTomoriNaoシールを手渡ししました。強制プレゼントっす。友利奈緒とTomoriNaoの知名度が上がるといいなー。何人かがマジで喜んでくれていたので嬉しかったにゃ。
Tomorinaoのシールもらった! pic.twitter.com/fXKE5IfHFL
— うさ (@usa3859) 2017年12月3日
TomoriNaoシールもらったので貼ったら案外存在感でかい pic.twitter.com/CEYuVdD6sW
— awamori (@awamori_tt) 2017年12月2日
※2つ目のはその場にいらしたライターさん。お渡ししたのは前日ですがね。
『カーネルエクスプロイトによるシステム権限奪取』
るくす さんの講義。セキュキャン全国大会2017での同氏の講義の事前課題を地方大会用に超易しくした内容。どのような脆弱性を使うのかの解説をすっ飛ばしてましたが、言われた通りにやればできる感じに調整されていました(が、事件発生!)。事前課題と同様、都合のいい脆弱なドライバーがユーザープロセスから与えたROPチェーンを実行してくれます。受講生がやるべきなのはROPに必要なアドレスを調べることです。ROPがうまくいくと、rootのシェルが立ち上がります。3人のエクスプロイトコードがカーネルに刺さったのですが、その後シェルが取れない、しかも講師もシェルを取れない、つまり全員講師と心中する結末となりました…。これはひどい
Kernel Exploitしてまーす! #spcamp #seccamp pic.twitter.com/VHd0Vf2Lfn
— セキュリティ・キャンプ (@security_camp) 2017年12月3日
画像右下をよ~く見てみると…
JRの切符を「名古屋ー西金沢」で買っていたので、帰りは「金沢→西金沢」の切符を追加で買いました。名古屋の自動改札機に通したら「乗車券区間非連続」と言って弾かれました。つまり、西金沢は微分可能ではない?でも、その後の有人改札では問題なしという判定だったので、自動改札機が微分をまともにできないポンコツだったんですな。あれま。
友利奈緒の好きなところ100個
これは 友利奈緒 Advent Calendar 2017 1日目の記事です。
カレンダーはまだ空きがあるのでなんか書きたくなったらどうぞー。
ども、友利奈緒(@K_atc)です。 皆さんのあの頃の感動を取り戻すべく、「私が思う」友利奈緒(本家)の好きなところ100個を挙げていきます!
《表記形式》
引用(
<quote>
ブロック):好きなところ
本文(<p>
ブロック):補足
容姿・性格
かわいい
無論大事。
それでいてガラが悪い
こんなやつが生徒会長
なんて生徒会なんだw!
「友利は、いわゆる恋愛シュミュレーションゲームのメインヒロインになるのは難しい気がします。(以下略」(*, p. 191)
とてもそう思う。
今の性格が中学の頃とは真逆という闇を抱えている
闇を抱えているのは人間らしくてよい。
自立している が、妹キャラというギャップ
ギャップ萌え~
激しい感情の起伏。まるでジェットコースター
「感情の起伏が今ひとつ掴みづらい友利。」(*, p. 165)
「友利は、どこか掴みどころがないというか、不思議なキャラクターであったという印象があります。(以下略」(*, p. 191)
内面的な良さ。見応えがあるね
困難に真正面から立ち向かう
暴力的だが、なんだかんだ思いやりが強い
基本はサバサバしてるが、認めた人にはデレてる
お昼は生徒会室で済ませる
昼休みに数量限定カレーを食べている乙坂らを容赦なく呼び出す
ひどい(でも好き)
面倒事は乙坂に押し付ける
なんかここは私に似てる~
リーダーポジションで、女性キャラの中では背が低い方(154.5 cm)
猫目
銀髪ツーサイドアップ
ツインテールじゃないよ!
私服のときはポニーテール
変化を付けてくるスタイル好き。あまりこれをするアニメが多くない
裾が長い白のフリフリのロングキャミソール
キャミソールの裾見せナシの作監指示(*, p. 16)
このちょっとした遊びとガードがいいね。
腰につけてるポーチ(ハンディーカムのケース)
(私もそのポーチ欲しい!ACOSの学園制服には本当のポケットが無くてさ…)
様態
ポッキー好き
口が寂しくなるとポッキーを食べる
なんと孤独な。これについては別の日に改めて言及します。
チョイスが渋い!当時はiPod nanoはあったでしょうに
高城が邪魔になったら蹴りを入れて病院送り
これ好き。
じっとカメラを構える
本編になかった描写な気がするな。どっかの二次創作で見たのかな…そんな友利奈緒好き
歩未には優しい
英語ができない乙坂のために英語表現の単語帳を作った
根っこは優しい人なんだけどね…拗らせとるね
セリフ+α
「引くなっ!」
これむっちゃ好き。本当はこれを10個ぐらい並べたい。
「釣れた!」
第1話にて第一声。単体で見るとどこのシーンで使われたセリフだよ!ってなる。
「スペアリブうっま!!」
「廃人になりたいんですか!人間やめたいんですか!」
「…っす」 「〜すよ」
友利奈緒の口調の代表格。
ゆさりんの新曲PVを視聴中の高城にハイキック
「歌が10点、曲が20点、衣装が20点、編集が30点、本人の痛々しさで-51点」
「しっかし、ルックスだけでモテそうなのに、カンニングしまくって秀才まで演じる必要があったのでしょうか?」
乙坂有宇には異性として興味がない様子
「そんな真顔で言われても、好意を抱かれるようなことはなかった気がするんですが…」
タイムリープで過去が書き換わってなかったことになった出来事があるということっす。
歩未の中学校(中等部)潜入時に、周りの生徒に「あの人もかわいい」(セリフうろ覚え)と言われて癇に障る
なんと不器用な人…
料理できる
圧 倒 的 正 妻 力
シーン等
椅子をリクライニングさせてリラックス
割り箸を口に咥えたシーン
ヒモを引きぬくだけで温まる「厚切り牛たん弁当」
「すっ、ごく、ない、です、か!」
このときの恍惚した友利の表情
あ゛ぁぁぁ
在来線の中で嬉しそうにほかほかの弁当を食べる
で、周りの迷惑は考えない
弁当を食べるシーンの逆再生バージョンがTwitterに存在(シュール)
逆再生バージョンがどのツイートにあったのかは覚えてないですけど。→逆再生太郎になろう(つくるぞ) - あまねけ!
逆再生太郎になろう(つくるぞ) - あまねけ! https://t.co/UsrMkPVDhy
— れっくす (@xrekkusu) 2017年12月6日
【2017/12/6追記】情報を頂きました。
星空をバックにした友利奈緒@エンディング
きれい。
キャンプ回で好きな音楽について乙坂と二人で話しているときにしていた生き生きとした表情
なめ茸回の皿洗いのシーン
(確かそのシーンで)歩未に「二人付き合ってるの?」と聞かれて「こんなのとはそれは無いです。アハハ」みたいな返答をしてたところ
この時の、この二人の間の空気感が好き。なめ茸回は2回あったけど、反応が微妙に違ったような…
「乙坂有宇君、おかえりなさい」
「これからは、楽しいことだらけの人生にしていきましょう!」
からの最高のにっこり笑顔エンド
とはいえネタバレ無しでこの流れの良さは筆舌に尽くし難いなぁ…
その他
謎のなめたけ推し
(作品を通して)謎の牛タン推し
牛タン弁当といい牛タンカレーといい…なんやこれ
奈緒がローマ字表記で3文字
nao――この無駄の無い感じがいいなぁ。
友利奈緒の語感
「ともり なお」。そうつぶやくだけでときめくね。
友利奈緒
この4文字の並び、いい!
「友利奈緒」の「はらい」の画の多さ
書いてみると分かるよ。
注釈
(*)『Charlotte 設定資料集』より
64個挙げました。残りの36個は読者の宿題ということで…
設定資料集は今読み返してCharlotte良かったなーと振り返るいい一冊です。てかウルッときました。今公式ショップは製品ページが消滅してるし入手困難かも‥?
ショップ - SHOPPING | 株式会社ピーエーワークス 公式サイト - P.A.WORKS Co.,Ltd. Web Site
Speaker Deckにまつわる実験
初回のアップロード
- ファイル名→upload-test.pdf
- タイトル→test
- 説明文→説明文A
- URL→https://speakerdeck.com/katc/test
変更した同名のファイルを再アップ
URLは変わらない
変更かつファイル名を変更したファイルを再アップ
URLは変わらない
- ファイル名→upload-test-C.pdf
説明文を変更
URLは変わらない
- 説明文→説明文Y
タイトルを変更
URLが変わった
- タイトル→test 2
- URL→https://speakerdeck.com/katc/test-2
青の部屋、赤の部屋、緑の部屋を思い出しますね~。赤の部屋はプロジェクターのところで当たり判定が厳しすぎて諦めましたわ。
nagoya.bin(名古屋低レイヤー勉強会)の第1回に参加しましたヾノ*>ㅅ<)ノシ
2017年10月29日(日)に開催されたnagoya.binという低レイヤーな勉強会に参加しました。この日のために肉体改造と2 kg減量しました。その程度の減量って意味あるのと思うかもしれませんが、「肉体改造」が肝です。この話は別の機会に書きます。
正装した友利奈緒として、シンボリック実行エンジンを自作した話をしました。資料はSpeakerDeckに上げてあります。 参加してない方も宿題やっていいですからね。
発表者は分かるが、発表内容はわからない、統一的なテーマも無い、そんな謎の勉強会にも関わらず、初心者を脱した専門技能をもった方々が集まっていました。 これぐらいは分かっててくれへんと10分に収まらんがなってとこはカットしましたが、そこそこ言いたかったことは伝わってた感じがしました。 互いの専門性の共集合は無いけど、それは大学でもやったなーってのが多かったので、個々の発表内容がすんなり入ってきました。
会場はMisocaさんのセミナールームでした。ありがとうございました。 マイク無しで声通るかな?しかもマスクしてるんに、と思いましたけど、奥行きが狭いので声を張らずとも声は届いていたと思います。 勉強会会場としてありっすね。投写も16:9オッケーみたいですし。そろそろ16:9で作るようにしたいね~。
描き下ろしたイラストです:
裏話をすると、このネタを作るためのプログラミング作業が10時間だったのに対して、イラストを描く時間が30時間ほど、スライドを100回以上修正するのに10時間ほどかけました。 このコストの高さは、趣味でやってるからできることっすね。大事にしていきたいです。
こうした規格を外れた創作活動は今後強化していきたいと思います。 皆さんの反応と自分のモチベーション次第では(3)がリリースされるかもしれません。 (2)はプロットができているので時間がとれるかどうかです…。 〈ダイジェスト版〉ってことはDay 3以降を含めた同人誌向けのノーカット版があるのかと思った方は鋭いです。それはノーコメントです。
太ももがまだ太いので筋トレは続けます!
VirtualBoxのWindows 10 VMに外付けHDDをマウントするのが大変だった
VirtualBoxのバージョンは5.1.128です。
Windows 10のVMでNTFSフォーマットされた外付けHDDをマウントするのが大変だったので解決手順を残しておきます。
USBデバイスを有効にするために、VirtualBox Extension Packをインストール
https://www.virtualbox.org/wiki/Downloads
この段階ではWindowsのデバイスマネージャでは身元不明のHDDとして認識されます。
次に、VMを一旦シャットダウンして、[設定] - [USB]の画面で、USB 2.0 (EHCI) コントローラを選択。
これでマウントできるようになります。
研究生活に役立つDocker入門
※走り書きです。
Dockerとは?+注意書き
※Linux限定で書いてしまうが、WindowsやmacOSでも利用可能
超軽量のコンテナ型仮想化を実現するOSSソフトウェア。VMのイメージで扱うと大変危険。 コンテナはシステムの資源を間借できる高機能chroot環境と思うのが吉。
Dockerでは、Linuxのカーネルをホストとコンテナで共有する。これはコンテナがLinuxカーネルの機能で実現されているからである。 コンテナの中から見えるファイルシステムは厳密に独立していないので、/bootとかは触ってはだめ(/etcはOK)。 systemd(pid 1系)は使えないので気をつけて。 先述の注意点がクリティカルな場合は素直にVagrantなりVirtualBoxなり使うのが賢明。
Dockerがなぜ研究生活向けなのか?
研究室で受け継がれるVMイメージはときに邪悪である。 OSのインストールは良いとして、その後に何をどうビルドしてインストールしたのかが全く明らかではない。 別にドキュメントを用意することが必要になってしまう。 また起動と実行のためにCPUとメモリを多く奪われてしまうのは全くイケてない。
Dockerを使って研究を進められる環境を作ると次のようなメリットがある。
- Dockerfile(後述)がそのまま環境構築手順書になる
- 起動が速く、ホストとシームレスにつながる(※ホストPCがLinuxの場合に限る)
- Dockerfileをgitなどでバージョン管理すると、いついつのときのコンテナを起動することができる(※image(後述)をビルドする時に細工が必要)
- システム変更を記録に残す癖がついて良い
- コンテナ起動後にした変更が破棄されるので、同じコンテナを使っている限り、システム側が原因で「前まで使えたのになぜか使えなくなった」が起こり得ない
- 試しにいじって上手く行ったらDockerfileに反映するアプローチも良し
ただし、以下のデメリットもあるので注意が必要。
- ウインドウマネージャの恩恵を受けられない(が、GUIアプリの画面を出すことは可能)
- 複数のターミナルを出すのがサーバーと同じくらい少し大変(が、こんなのは慣れの問題)
- Dockerfileを変更してコンテナを更新するまでに大変時間がかかることがある(変更方法に依存するが、覚悟が必要)
- Dockerfile作成にあまりネットで言及されないコツが必要(後述)
インストール方法
Ubuntuは以下の記事で良いと思われる。 [Docker] ubuntu 14.04/16.04にDockerをインストール - Qiita
Arch Linuxの場合は、
sudo pacman -S docker ### 自分にdockerグループを追加 sudo usermod -aG docker `whoami` ### dockerを自動起動 sudo systemctl enable docker
ここで完了させておくことは、
- dockerのインストール
- ユーザーにdockerグループを追加
- dockerデーモンの有効化(ないしは
sudo docker daemon
をLinuxが起動する度に手動実行)
である。
コンテナ起動
コンテナ起動時に実行するプログラムを指定する。通常はbashを起動する。 後述するDockerfileにCMDとして起動するプログラムを明示していないケース/誤ったCMDの指定がされることがあるので気をつけること。 Dockerfileを信頼せず、コマンドラインで明示するのが安全である。
コンテナ起動のコマンドは次の通り:
### ubuntu 14.04の場合 ### オプションは "run it" で覚えるのがおすすめ docker run -it ubuntu:14.04 bash #### runの前に `docker pull ubuntu:14.04` が必要かも ### プロセス終了時にコンテナを破棄したいとき(--rm) ### オプションは "run, remove it" で覚えるのがおすすめ docker run --rm -it ubuntu:14.04 bash
動作確認のために上記コマンドを実行してUbuntuのbashシェルが出ることを確認してほしい。 ネットワークからimageがダウンロードされるので初回の起動は時間がかかる。 imageとはコンテナを起動する種になるものである。 これは次節で説明する。
高度なコンテナ起動オプションとDockerあるあるについては後半で述べる。
imageの作成
imageはコンテナ起動の元になる「種」のようなものである。 imageの作成は2通りの方法がある。
Dockerhub Dockerfile | | pull build | | [ image ] | run | [ container ]
1つ目はDockerhubからpullする方法である。あまり使わないので説明は省略。気になる人は「docker pull dockerhub」でググって。
2つ目はDockerfileからbuildする方法である。 Dockerfileはこの名前で存在するファイルである。 Dockerfileがあるディレクトリまで移動(cd)して、
docker build -t IMAGE_NAME . # IMAGE_NAME must be lowercase ### or docker build -t IMAGE_NAME -f DOCKERFILE_PATH ### without cache docker build -t IMAGE_NAME . --no-cache=true
のどれかの形式で実行すると良い。IMAGE_NAMEは制約があるので小文字でいい感じに付けると良い。 buildはキャッシュを使ってされる。apt updateで不都合が起こる時はこのオプションを付けるとよい。
Dockerfileの構成
大抵の場合上の行から、
- FROM(必ず1番上に書くこと)
- MAINTANER(省略可)
- RUN または ADD または ENV または WORKDIR または USER(これが複数行続く)
- CMD または ENTRYPOINT (省略可;1行のみ)
の順に書かれている。
FROM
FROMはベースとなるimageを指定する。何も考えずに
FROM ubuntu:16.04
か
FROM ubuntu:14.04
と書くといい。
MAINTANER
メンテナーの情報を書く欄。自由に
RUN
ベースのimageで実行するコマンドを書く。複数行に分けたい時は行末に「半角スペース+バックスラッシュ」
例えば、
RUN sed -i.bak -e "s%http://archive.ubuntu.com/ubuntu/%http://ftp.iij.ad.jp/pub/linux/ubuntu/archive/%g" /etc/apt/sources.list && \ apt update && \ apt install -y git automake pkg-config libssl-dev RUN apt install -y curl wget bash-completion net-tools strace silversearcher-ag mlocate vim
シェルスクリプトの要領でガリガリ書いていく。コマンドはroot権限で実行されるのでsudoは付けなくて良い。 ちなみにRUNごとにキャッシュが生成される。
1つ前のRUNでcdして、次のRUNでそこの場所でコマンドを実行はできない。RUNごとにカレントディレクトリがリセットする。 cdのし忘れには気をつけよう。面倒な時は後述のWORKDIRが便利。
ADD
外部ファイルをimageに追加するコマンド。Dockerfileから見た相対パスで書く。 パッチファイルを取り込みたいときに便利。
ADD ./my-awesome.patch /home/docker ADD ./my-awesome.patch $PATCH_FILE_DIR
面倒でなければENVで設定した環境変数を使うようにしてください
ENV
docker buildで有効な環境変数を設定するコマンド。$HOMEを変更するときはWORKDIRを使わないとだめ。 以下例。
ENV PATCH_FILE_DIR /home/docker/projects/qemu/patches
WORKDIR
カレントディレクトリを変更するコマンド。 以下例。
WORKDIR /home/docker/projects
これをするとその後のRUNから/home/docker/projectsがカレントディレクトリになる。
USER
コマンドの実行主を変更するコマンド。このときユーザーが自動的に作成されるかは知りません。
USER docker
CMD, ENTRYPOINT
両方は使えなかったはず。複数回もできなかったはず。 コンテナが起動したときに自動実行するコマンドを指定できる。 どっちかが、コマンドラインで指定したコマンドに置き換えられるはず。
Dockerfileのトラブルシューティングのコツ
- 前もって別の環境で実行して、このコマンドで上手くいくことを確認する
- apt updateを冒頭で必ずする
- ファイルがあることを確認するために
RUN ls *
する - buildメッセージに載っているキャッシュされたimageのIDを控える→
docker run --rm -it CACHE_IMAGE_ID
してインタラクティブに確認【一番オススメ】 - RUNの単位を細かくする。
&&
で頑張って繋げない - RUNで複数実行するときは
;
でなく&&
でコマンドをつなげる
日頃気をつけること
- システムに残したい変更をしたら、そのときに実行したコマンドをDockerfileに残すのを忘れないこと。
高度なdocker run
privillegedオプション
Dockerのコンテナは触れるシステム資源が制限されている。 USBはこれに該当する。USBを使えるようにする前提で説明する。
まず Dockerfile 後半に以下の行を追記する必要がある。
VOLUME /dev/bus/usb:/dev/bus/usb
これは、ホストとコンテナの間でUSBを共有する設定。
privilegedモードでの起動は
docker run --rm -it --privileged IMAGE_NAME[:tag] bash
特権が付いているかどうかは次のように確認できる。
コンテナの外から:
docker inspect --format='{{.HostConfig.Privileged}}' CONTAINER_ID
コンテナの中から:
ip link add dummy0 type dummy
デタッチしたコンテナを復活させる
--rm
を付けずにdocker runした場合のみ。
docker run で起動したbashをexitしたとき、コンテナはdocker ps
(※起動中のコンテナを確認するコマンド)には表示されなくなる。
次の手順でコンテナIDを取得し、re-attachすることができる。
### check container name or ID docker ps -a ### wakeup contianer with its id or its name docker start CONTAINER_ID/CONTAINER_NAME ### you can check your container restarted docker ps ### now you can re-attach to it docker attach CONTAINER_ID/CONTAINER_NAME # hit ENTER
docker attachしたターミナルで、アタッチ後にEnterを押さないとプロンプトが返らないことがある。
ショート版の手順がこちら:
docker ps -a docker attach `docker start CONTAINER_ID/CONTAINER_NAME`
tmux
シェルが1つしかないのは不便なので、tmuxのようなターミナルマルチプレクサを使うとシェルをいくつも開けて便利。
VirtualBoxみたいにファイル共有(フォルダ共有)したい
起動時に「-v マウント元(ホスト上のパス):マウント先(コンテナ上のパス)」のオプションを与える。
-v A:B -v C:D
の感じで複数並べることも可能
### read-write mode docker -it -v VOLUME_NAME:/home/guest docker -it -v `pwd`/HOST_DIR_NAME:/home/guest ### read-only mode docker -it -v VOLUME_NAME:/home/guest:ro docker -it -v `pwd`/HOST_DIR_NAME:/home/guest:ro
高度なdocker build
docker build を一々叩くのは面倒なので ./build.sh なり、ビルド用のシェルスクリプトを用意すると便利である。 docker buildに成功したらタグを付けるようにしたほうがいい。タグ名はちゃんと管理できる自信があるならバージョン番号でも良いし、 gitのコミットハッシュでもよい。後者を前提とした build.sh のテンプレートが以下:
count_x_files() { COUNT=$(git status --porcelain | grep -v "/patch/" | grep $1 | wc -l) echo $COUNT # return $COUNT } IMAGE="my-ubuntu" docker build -t $IMAGE . || (echo "[!] ERROR: docker build. exit" ; exit) echo "[*] DONE: docker build" if [ $(count_x_files "MM") -ne "0" ]; then echo "[!] There's not staged changes. git add it now"; exit fi if [ $(count_x_files "??") -ne "0" ]; then echo "[!] There's untracked patch files. git add it now"; exit fi docker tag $IMAGE $IMAGE:$(git rev-parse --short HEAD) echo "[*] DONE: docker tag"
このテンプレはgit add -u && git commit のし忘れを指摘してくれる。
Dockerあるあると小ネタ
コンテナーのIDを知りたい
docker ps
(docker buildで作成された)特定のコンテナのログを見たい
docker log CONTAINER_ID
ID は docker build のログ Running in dc043f01ca19
から dc043f01ca19
を拾ってくる
imageの一覧を見たい
docker images
イメージを消したい
### remove specific image docker rmi IMAGE_NAME [IMAGE_NAME ...] ### force remove docker rmi -f IMAGE_NAME [IMAGE_NAME ...]
イメージ名を改名したい
### copy docker tag OLD_IMAGE_NAME OLD_IMAGE_NAME ### and remove docker rmi OLD_IMAGE_NAME
停止したコンテナだけ一覧で出したい
docker ps --filter "status=exited"
使ってないコンテナ(exitしたコンテナ)を消したい
docker rm `docker ps --filter "status=exited" -q` ### or docker rm $(docker ps -a -q)
タグがついてないimageを消したい (like <none>:<none>
)
docker rmi $(docker images | egrep "^<none>" | awk '{print $3}')