mount --bind こわい

mount --bind こわい @silpheed_kt Keiichi Tanaka ssmonline #45 2024/11/28

mount --bind こわい 自己紹介 @silpheed_kt Keiichi Tanaka • • • • • 少しPM 少しプログラマー 少しインフラエンジニア 少しネットワークエンジニア サイバーセキュリティ系の何か ssmjpのSlackでは主に #dtm にいます。 Misskey.io : @[email protected] ssmonline #45 2024/11/28

mount --bind こわい はじめに • 本LTは録音、録画、SNS投稿OKです • 本LTの内容は無保証です • 個人の見解です（所属する組織等のそれではありません） • ゆるいです • そんなのみんなしってるという内容かもしれません ssmonline #45 2024/11/28

mount --bind こわい VMこーわーれーたー chrootしてscpでファイルをコピーする環境の構築に失敗して、 切り戻し作業時にuserdelしたらVMが反応しなくなった。という報告をいただきました。 （タイトルとchrootですでにネタバレ気味ですが…） ssh不可。 ハイパーバイザのWebコンソールからログイン不可。 こわれたのはしかたないー。なおすかあ。 ちなみに、 chrootとは、指定したディレクトリを仮想的なルートディレクトリ（/）に設定し、プロセスをその中で隔離する Linuxのコマンドまたは機能です。主な目的は、セキュリティの強化やテスト環境の構築です。この環境では、 プロセスは仮想ルートの外にアクセスできません。 （ChatGPT先生より） ssmonline #45 2024/11/28

mount --bind こわい なんでこーわーれーたー レスキューモードで起動（OSはRHEL系）。 ログを見ると systemctl がエラーを出してる。 Failed to switch root: Specified switch root path ‘/foo’ does not seem to be an OS tree. OS-release file is missing. OS-releaseファイルは /etc/os-release にあるがこれの実態は /usr/lib/os-release 。 /etc/os-release のシンボリックリンクはある。 ls /usr/lib –al からっぽ。/usr/lib64も。 まじかあ。 ssmonline #45 2024/11/28

mount --bind こわい 本番環境「から」復旧 こわれたVMは開発・検証環境で、 それをクローンして本番環境にした（当時のにゃーんのため）。 なので開発・検証環境と本番環境のVMはOS・システム的にはほぼ同じ。 一応、OSのインストールISOイメージから/usr/libと/usr/lib64をコピーしてみたが、ファイルが足りなくて起 動できない。 本番環境の/usr/libと/usr/lib64をコピーする方針で作業。 シンボリックリンクごとコピーしたかったのでrsyncしたかったが開発環境へ向けてsshを疎通されるわけにも いかない。 本番環境にあった稼働準備中のVMに仮想ディスクをext4で作成、アタッチ、マウント。 そのVMに本番環境からrsyncで/usr/libと/usr/lib64をコピー。 仮想ディスクをこわれたVMにアタッチ、マウントしてファイルを書き戻し。 ssmonline #45 2024/11/28

mount --bind こわい なおったー こわれたVMは無事起動。sshdも起動。 壊れた内容が/usr/libと/usr/lib64が消えただけだったのでウワモノも問題なく起動。 一応の復旧。 めでたしめでたし。 というわけにもいかない。 ssmonline #45 2024/11/28

mount --bind こわい 根本原因 切り戻し手順の不備 切り戻し時にマウント解除せずにuserdelした。 （たぶん/etc/fstabから消して再起動後にuserdelする必要があった） 設定手順の不備 手順書が微妙に間違っていた（または解釈が揺れる余地があった）。 同じ手順をトレースしたが期待する結果が得られなかった。 ssmonline #45 2024/11/28

mount --bind こわい 流出原因 レビュー時の見落とし 設定手順、切り戻し手順の不備（や解釈の揺れる可能性）を見落とした。 見落としの原因は？ 設定内容を理解するコンテキストが不足していた。 （諸々のにゃーんに起因する）注意力不足、「大丈夫だろう」的な思い込みがあった。 その他いろいろなにゃーんは割愛。 ssmonline #45 2024/11/28

mount --bind こわい sｆｔｐ利用に手順書を改定 scpでなくてもよいのでは？ 当初chrootせずにscpでコピーする方針が chrootしてファイルコピーだけできるようにするという要件に変わった（安全のため）。 chrootしてscpする方針としたが、要件を満たすためには、ｓｃｐの使用は必須ではない。 →sftpに変更し無事設定完了。 sftp採用の理由 mount --bind が不要になるのですくなくとも今回の問題が発生する可能性がなくなる。 chroot配下のlib、lib64の構築、管理が不要になる。 （mountしない場合ファイルをコピーする＝管理対象の増加） ssmonline #45 2024/11/28

mount --bind こわい コストのバランス（なやみその1） 理解のためのコストと全体のコストのバランス きちんとレビューします…という反省。 （わからないところは放置しない） いっぽう、復旧作業時に状況報告毎に上司がすべて正しい手順を提示してくれていた。 それをトレースすればおそらく迅速な復旧はできたが「わからないところは放置しない」で調査等を行ったた め結果的に時間はかかった。 （OSイメージからの復旧を試みたり、等） そのバランスはどうするべきか？ 今回は比較的時間に余裕があったので、まったくの誤りではなかったと思っているけど…・ ssmonline #45 2024/11/28

mount --bind こわい コストのバランス（なやみその2） 手順書の粒度 誰が実施しても100％成功する手順書が良いと思っている。 （コマンドをコピー＆ペーストして実施すればよい、くらいの内容） 「そうでない手順書」も存在する（特定の人員しか、トレース・再現できない）。 「1文字違うと全然違う」系の操作をどうするか。 思い込みや操作ミスをなるべく減らすためにはどうすればいいか。 （sftpに変更したのはより明瞭な操作で設定できると判断したというのもある） もちろん、作業前にバックアップやスナップショットを取る、というのも有効。 今回の例にはあてはまらないが（手順書の誤りが原因のため）、 「そうでない手順書」に基づく作業は、作成者にお願いしてしまう、というのも短期的にはアリかもしれない。 ssmonline #45 2024/11/28

mount --bind こわい まとめ 理想として、やることはきちんとやりましょう。 やりきれないときは、それをカバーできる何かを考えておきましょう。 やること、やらないことのバランスって難しいですね。 何か良いアドバイスがあればハッシュタグ #ssmjp でぜひお聞かせいただければ幸いです。 にゃーん。 ssmonline #45 2024/11/28

mount --bind こわい ご静聴ありがとうございました ssmonline #45 2024/11/28