おっと、もう出るのか。買わなくちゃ。
ご存知パスワード・クラック/脆弱性チェック・ツールの定番。試しにpam_cracklibが導入されてない開発用マシンでcrack実行してみたら、ぞろぞろ出るわ出るわ。即刻、該当者全員に教育的指導。開発機だからってナメてちゃいかんぞ、と。
「本日のリンク元」から発見。こういうのってとても日本的なサービスって気がするなあ、とか思ったり。
しかし、こういうの見るとビジネスモデルはどうなってるんだろ？とか考えてしまう私。運営母体はこの会社なのかな。このページは「こうさぎ」とは別のRSSリーダーの説明だけど、こうさぎでもこういうのを最終的に狙ってるのかな。Google Ad Senseのカワイイ・バージョンみたいな感じか。
パスワードつながりで思い出したので、前にも書いたような気がするが、おねがいだからパスワード入力をexpectで自動化なんつーバッド・ノウハウをWebで広めないでくれ。子供がマネするから。googleで検索すると山ほど出てくるんだよな。ほんとマネするんだよ、子供は。あ、あとcronとかからssh/scpするのにssh-agentでパスフレーズ入力を自動運転ってのもバッド・ノウハウな。
正しいssh/scpの自動運転は:
- 自動運転専用の鍵をパスフレーズなしで作成する。
- でもって、その鍵を使ってやれることを、いかにして必要最小限の作業だけに制限するかを考える
が正解(現時点では)。
必要最小限の作業に制限する方法としては、
- 毎回完全に同じコマンド(引数含めて)しか実行しないなら、authorized_keysでcommand='...'を使って実行できるコマンドをそれだけに制限。
- ファイル転送用途だけなら、scponlyとかの転送用途に限定されたシェルをリモートのアカウントのシェルに設定する。
- 上記2つのケースには該当しないけれど、特定のコマンドに実行を制限したい時はrestricted shellとか。
- 可能ならchroot patchをあてたsshdを使ってchroot環境作るのも良い。
- あるいはauthorized_keysのcommand='...'機能を使って強制的に特定のコマンドを実行された場合に、本来リモートから(ssh host 'cmd...'等で)与えられたコマンドラインが環境変数SSH_ORIGINAL_COMMANDに保存されるのを利用して、SSH_ORIGINAL_COMMANDを自前で安全に処理するコマンドを作るとか。
とかって方法が考えられる。さらに、どうしても必要最小限のコマンドに制限できない場合は、接続元のホストを制限した上で接続元ホストの方を守るのと、実行されたコマンドのログをacct等で確実に取る(必要ならアラートも飛ぶようにする)。
あと、意外に多い誤解が、「パスフレーズなしの秘密鍵は(パスワード認証における)パスワードなしと同じくらい危険」とか、「秘密鍵のパスフレーズを変更すると、公開鍵も変化する(公開鍵の設定しなおしが必要)」とかって誤解な。
秘密鍵のパスフレーズは秘密鍵ファイルを暗号化してるだけのもんです。暗号化された秘密鍵をパスフレーズつかってデコードする処理は、完全にローカルで行なわれて、リモートのサーバには丸っきり関係がない。逆に言うと秘密鍵ファイルを悪者に盗まれてしまったら、たとえパスフレーズが設定されていても、↑のCrackみたいなオフライン攻撃が可能、つまり悪者は手に入れた秘密鍵をどっか別の安心して作業ができるマシンでじっくり辞書攻撃なり総当り攻撃なり使ってパスフレーズを探すことができる。
なので、「秘密鍵を他人に渡さない」ということの方が、パスフレーズを設定することよりも遥かに重要。パスフレーズはいざという時の時間稼ぎでしかない。
それが分かれば、ssh-agentやkeychain使うより、いさぎよくパスフレーズなしにしちゃった方がいいってのも分かると思う(自動運転の場合ね)。だって、適切なパーミッションが設定されている秘密鍵ファイルを盗める人間(rootとか)なら、常駐しているssh-agent/keychainも乗っ取れるでしょ。パスフレーズ設定してる意味がない。「なんかの拍子にssh-agentのプロセスが死んじゃってて(めったにないけど)、自動運転に失敗した」とか、「サーバをリブートするたびに、パスフレーズ入力してssh-agent起動しないといけない(運用担当者全員にパスフレーズ教えないといけない)」とかって、余計な手間が増えるだけ。
そんなことにいらん手間かけるぐらいなら、秘密鍵が盗まれちゃった場合でも被害が最小限で済むように(↑で書いたような実行可能なコマンドの制限等の対策を)がんばった方がいい。
追記(2004/11/22):authorized_keysの設定で権限を制限する場合、当然だけどauthorized_keys自体を書き換えられる権限を与えちゃダメ。authorized_keysを書き換えられないようにするには、リモートマシンのrootを取れるなら、authorized_keysのownerをrootにしちゃうのが手っ取り早いかな。(追記:2005/02/26) あ、authorized_keysだけrootにしてもダメで、ユーザーのホームディレクトリと、~/.ssh もユーザーに変更不可にしとかないとダメだけど。これも参考にしてくれい。
追記2(2004/11/24):そいや会社で、パスワード/パスフレーズをファイル(たとえばexpect使うスクリプト)に書いて転がしておくのと、パスフレーズなしの秘密鍵転がしておくのと、なにが違うん？という至極もっともな質問をされたことがあるんだけど。
答えは「なんにも違いません」だな。パスワードの方が可読性が高くて短いってことぐらいで。
リモートホストへのアクセスを自動運転するって時点で、認証に必要な情報をローカルホストに常駐させなきゃいけないので、どんなやり方したって理屈上は、ファイルにパスワード書いて転がしておくのと変わるわけがない。ただ、転がし方によっては認証情報をかっぱらうのがちょっと面倒なだけ。obfusticationはできても本当の意味で守ることは不可能。
だから認証は取られちゃうものとして、取られても不正な操作ができないようにリモート側で制限をするというのが正しい、という話であって、パスフレーズなし秘密鍵がexpect使ったスクリプトより安全、という話ではないことに注意してほしい。
すぎょいな。外装だけのなんちゃってナイトライダーじゃないんだ。
Prodigy新譜。8月に出るらしい。もう活動してないんだと思ってたよー。買わねば。
rubyのまつもと氏がメールを「検索」で分類することをメインにしたMUAが欲しい、みたいなことを最近書いている。
なんか昔、ジャストかどっかの製品でそゆのがなかったっけ？そして中村正三郎かなんかがそれを誉めてたような気が。
で、オイラも昔からそゆの欲しいなーと思ってるんだけど、確かにないよね。QMAIL(not qmail)には、検索フォルダ？ってゆー概念があって、検索条件をフォルダのように見せかけることができて、これが現存では一番オイラの欲しいものに近いかなーと思うんだけど、いかんせん完全にフォルダ代わりに使えるほどには検索が速くはない。まつもと氏の考えてることには激しく同意なので作っちゃってくれないかなーと思ったり。
で、さらにぜんぜん関係ないのだが、MUAとは別に「インデックス更新が高速(ほぼリアルタイム)な全文検索システム」ってのが欲しいなー、というのを最近お仕事方面で思ったのだが、ちょろっとぐぐったところではそゆのってないみたい。せいぜいメインのインデックスの他に、更新された分だけの差分のインデックスを持つことができますよ、ぐらいなもん。
とゆーわけで、とっかかりになるかもしれんので参考文献として、とりあえずこのへんメモっとこ。
自分は小泉/自民党と違ってちゃんと謝ってる、とか開きなおってるみたいだが、公務員の兼職禁止規定なんて常識だろ。知らなかったなんてちゃんちゃらおかしいし、本当に知らなかったんだったらバカすぎ。つか、民間だって普通兼職禁止の社内規定ありますが。
都内の予備校が名誉毀損で掲示板の管理人を訴えたのを、東京地裁が表現の自由を理由に退けた、とゆー話。
2chでもこのテの訴訟はじゃんじゃん起きてるわけだけど。大昔からある「ヒトの噂」とゆーものが電子的に記録されるようになった、ってだけのことなんじゃないの？と思ったり。
てゆーか、否定的な論評ってのはことごとくネガティブなインパクトを持ちうるわけだけど、ネガティブなインパクト(を与える可能性)があったってだけで、名誉毀損で有罪になっちゃったら、公開の場で何かを論評するなんて不可能だわな。
「『キャシャーン』はクソ映画だ」とかって言っただけで、松竹に訴えられたりする世の中がこないことを祈る。
他のことはさておいて、
「著作権制度は民主的な手続きを経て成立している。その中で1人の天才技術者が、制度に対して技術的にテロのような状況を起こすことには怒りを禁じ得ない。非常に非民主的な行為だと考えている」（久保田氏)
久保田氏とゆーのはACCSの専務理事。
既存の公序良俗に反する技術は存在してはならないってのは、これはこれで『1984』的な思想だよな。
ウチの会社に銀行出のバカ部長がいるんだが、まさにこんな感じだな。何もしなければ責任を取らされることはない、絶対に自分が責任を追及される恐れのないケース以外では、なにもしないとゆー行動原理。
Nice site!
[url=http://uxvvovta.com/ehjo/fcki.html]My homepage[/url] | [url=http://ujxltmze.com/tcjj/mygh.html]Cool site[/url]