Mac OS X USB Keyboard Root Access

mac 管理 security

SecureMac.com に、『Mac OS X USB Keyboard Root Access』と題されたAdvisoryが掲載されています。



要旨としては、Mac OS Xでは起動時にCommand＋Sを押しておくとシングルユーザで起動しますが、実はControl＋Cを押しておくことで、initがクラッシュしてしまいシングルユーザモード（と同等のroot shell prompt？）でログインできてしまうというものです。
影響範囲は、Mac OS X 及び Mac OS X Server 10.2.8以前の全てのバージョンです。Pantherには影響しません。
前述のAdvisoryには「Mac OS X 10.2.7以前（恐らく10.2.8も）」の様に書かれていますが、10.2.8も影響します。
また、Mac OS X Serverに関してはAdvisoryに書いてありませんが、これも影響します。



一般的に、シングルユーザモードでの起動を制限する方法としてはAppleの提供しているOpen Firmware Password 1.0.2（参考：Open Firmware Password 1.0.2 に関する情報とソフトウェアのダウンロード（TIL））の使用が有効なのですが、このControl＋C押しでの起動では、Open Firmware Password 1.0.2を用いたパスワードプロテクトを回避してシングルユーザモードでログインできてしまいます。



悪意のある者にControl＋Cキーを押しながらマシンを起動されてしまうような事態では、既に物理的アクセスをマシンに対して許してしまっているということですから、この問題に対処する必要を感じない方もいるかもしれません。
ですが、もしこの問題に対処したいと考えるのであれば、以下の様にOpen Firmwareでのパスワードプロテクトを有効にして下さい。
ただし、以下の文章の意味が分からない場合には実行しない方が良いでしょう。また、実行する際は全て自己責任でお願いします。

  1. マシンの起動時にCommand＋Option＋O＋Fキーを押しておき、Open Firmwareを呼び出す。
  2. passwordと入力
  3. パスワードを入力するよう求められるので、適宜に入力（これがOpen Firmwareのパスワードとなる）
  4. 確認のために、再度パスワードを入力
  5. setenv security-mode fullと入力
  6. reset-allと入力し再起動

これで、マシンの起動時に必ずOpen Firmwareのパスワードを求められるように設定され、Control＋C押し起動でシングルユーザモードに入られることも無くなります。
なお、Open Firmwareのパスワードプロテクトを解除するには、

  1. Command＋Option＋O＋Fキー押しで起動
  2. setenv security-mode noneと入力
  3. Open Firmwareのパスワードを聞かれるので入力
  4. reset-allと入力し再起動

とします。



以下の参考情報にも必ず目を通し、まずはこの問題に対処する必要があるかどうか判断してみて下さい。



なお、この問題が修正されるかどうかについて、Appleからの発表はまだ無いようです。



追記：古暮さんの投稿である[harden-mac:0537] を追加。
推測を交えてらっしゃるとはいえ、かなり納得できました。

今度はFileVaultのトラブルについて聞き＆見回ってみた

mac 管理

以前とは打って変わって、どうもトラブルを聞くような気がするので今度はトラブル情報を収集してみた。
というのも、

んで、こりゃマズかんべぇ、と。んで、情報収集だと。そんなのより早く入れたい気持ちを抑えつつ。つか先入れろ＞オレ、みたいな。ま、それは良いとして。



で、以下トラブル情報。

日本語の奴は全部アップルの方のDiscussionsだから、要アカウントなのかな。



しかしなんつーか、読んで回った限りでは「（現時点では）FileVaultステかのう...」って印象を受けてしまったんですが。
期待してたんだけどなぁ。FileVault。
って、あぁ、私まだ入れてませんからね。私の印象とかアテにしないように。



で、どうよ？＞id:t_traceさん。　不具合ってる？
# いや何か最近、「脆弱ってる？」とか「不具合ってる？」とか聞く人いたらしいよ。某スレで（笑



追記：id:DayTripperさんが『FileVaultを切ってからの動向』で、FileVaultを切ったら 特に問題なし との事。んー。何で問題起きるんだろうなぁ。んー。



再度追記：たまちゃんさんに関する部分、書き方がまずかったかなぁということで修正。



さらに追記：id:t_traceさんが『FileVaultの動作と不具合』をアップされています。とても良いドキュメントだと思います。正直「ヤラレタ」とか思ったり（藁　いやしかし有難い。

しかし何故にFileVaultの不具合って起きるのか？

mac

以下、私的なぐり書きなんで、気にしないで下さい。読んでもきっと訳わかんないと思います。



追記：以下はほぼ完全に間違っていて、今（2003.11.04 21:15）となっては単なる私的メモの役割しかないので、読む価値が無いどころか読まない方が身のためとゆーか、正直 id:t_traceさんの『FileVaultの動作と不具合』を読んだ方が良いです。



しかし、FileVaultがどう実現されてて、どうして不具合が起きるのか気になる。
そもそもsparseimageの初期サイズをどうしてるんだ？とか、stretch オプション与えといて足りなくなったら後から拡げるんだろーか？とか、id:t_traceさんの『FileVaultで初期設定に戻るのは…』とかどーなのよ？とか、ね。
つか、私の勝手な超てきとーな予想を言いますが信用しないよーに。てか、自分にしか解らないかも。一気にメモ書きするから。てか、こんなのがハズレても笑わないで下さい。ヒー。どっかの雑誌にでも既に載ってたりしてね（笑



えとね、上書きとかでアップグレードしたような元からユーザのホームディレクトリがある場合ね、これは、正確なオプション名忘れたけど、hdiutilでtarget directoryを指定しつつ、AES-128な暗号化を施しつつ、sparseimageに変換。
ただ、sparseimageの容量とかどう計算してるのかがとても気になる。予めあるディレクトリの総容量に適当なマージンを付与してsparseimageのsizeを規定しつつ、stretchオプションで更に起動パーティションの空き容量から勝手に算出して適当にかなり大きめに「広げられるsize」を指定してるのかも。
クリーンインストールとかでまるっきり新規ユーザ作ってFileVaultかける時は...どうやってsize考えてんのかね。考えないのかなもしかして。限界まで-stretchのsizeを与えてあるのかなぁ。
んで、ユーザがログインしてる間。id:t_traceさんの『FileVault』の『FileVaultとファイル共有』あたりを読んで、-shadowを使ってるのかな、とか。
でだ、ユーザがログイン（＝sparseimageが自動展開されて/home/hogeになる）してゴニョゴニョし、ログアウトすると。
ゴニョゴニョしたのは、実はsparseimageを展開した/home/hogeじゃなくて、shadowfileに書かれてる。
で、もともとsparseimageを作った時に余裕をもったsizeにしてあって、そのsizeに収まるゴニョゴニョであれば、ログアウト時にshadowfileから直で/home/hogeにゴニョゴニョが反映されて、アンマウントされてsparseimageに戻る。その場合は恐らく不具合が起きないんじゃないか。
ゴニョゴニョがそのsizeに収まらない場合。各所で話題の「復旧」が為されるんじゃないかと。実際に何やってるかって、展開されたsparseimageである/home/hogeを一度アンマウントしてsparseimageに戻し、hdiutil resize （だっけ？）してsparseimageを拡張してるんじゃないかと。shadowfileの大きさに基づいて＋α位で。コレ激しくいー加減な予想。
だから、/home/hogeアンマウント＝sparseimage化→hdiutil resize→sparseimage再マウント→shadowfileから/home/hogeに書く→/home/hogeアンマウント＝sparseimage化、みたいな。
んでね、shadowfileの内容が/home/hogeに反映される前に、一度アンマウントされちゃうじゃない。で、さぁid:t_traceさんの同じく『FileVault』の『FileVaultとファイル共有』では、~/Library/Preference/ByHostはsparceimageの外にあるらしいじゃん。つまりさ、一度アンマウントされちゃうことで何かがオカシクなるのかな、と。何じゃそら＞オレ、と。



以上、そんないー加減ななぐり書きでした。読み返す気にならない自分がいたり（笑