アカウント名:
パスワード:
スクリーンロックを解除するためにはパスワード入力が必要です。確かに何らかのプログラムが必要ですが、単に何らかのプログラムを起動しただけではパスワードを知ることは出来ません。しかしロック画面を表示することで自然な形でパスワードを収集出来ます。また一般ユーザ権限のプロセスでも、管理者ユーザのロック画面などに偽装することで、管理者権限を得ることが可能かもしれませんし、共用PCならばログイン画面に偽装して他ユーザのパスワードを収集することも可能かもしれません。＃そういった画面に偽装しなくても騙される人はいるからパスワード収集は可能ですが、偽装できればさらに効率は上がるでしょう。＃ブラウザのアドレスバーやダイアログの偽装とかも類型と言えるかな？
NT系でCTRL+ALT+DELキーが必要なのは、これがプロセスによりトラップするなどで無効化できないものであるからです。＃ということをユーザが知らなければ意味がないのですけれどね。
異なる機能のものを比較しても意味があるとは思えません。「NT系でCTRL+ALT+DELキーが必要」というのはローカルの話で、X は基本的にネットワークベースです。
Windows であってもリモートデスクトップ越しにスクリーンロッカーに見えるものを解除する時、Ctrl + Alt + End を受け取ったローカル側のプロセスが、正しいリモートデスクトップなのか、そういった画面に偽装したパスワード収集ソフトなのかを判別できないのではないでしょうか。
windowsはCtrl+Alt+Delのトラップを無効化してるので偽のスクリーンロックを見破れますって話でしょ
ええとですね、2015年の今現在Xをネットワークに生で流すことは推奨されていないのです。XはデフォルトではUnixDomainしかlistenせず、tcp:6000を開けるならsshのポートフォワードを使うことが強く推奨されています。Xはネットワークベース？古き良き時代はそうでした。今はローカルのレンダラですよ。
ええとですね、2015年の今現在Xをネットワークに生で流すことは推奨されていないのです。
ロックされているように見える画面に対し、パスワードを入力する前に、正しい相手かどうかの識別を CTRL-ALT-DEL という特定のキーコンビネーションに反応するかどうかで判断する、というのはローカル OS などキーボードに対し絶対的な権限をもつものの設計としてしか意味がないのでは、という話です。Windows のリモートデスクトップにせよ、X にせよ、（X サーバと通信する）クライアントプロセスがロック解除のためのパスワードを処理するならば、ローカルのキーボードに頼ることはそもそもできないでしょう。
Wayland で UI を握って云々という話は、CTRL-ALT-DEL や Windows キー+電源ボタン並になることはあっても、本質的な解決とは思えません。
そもそも、問題の本質は、ユーザである人間が、パスワードを教えて良い正しいプロセスかどうかを「認証」するにはどうしたら良いか、ということです（別に認証が正しくてもキーロガー等で「盗聴」されているかも、という問題もありますが）。（ネットワークや多様なハードウェアを想定した）ハードウェアの仮想化、例えば Windows や iOS 上のアプリケーションから利用する、そもそも物理キーボードがない場合などを考えると、抜本的にはパスワードを使わずにGoogle Authenticator [wikipedia.org]などで TOTP 認証にするなど、別に「鍵」を用意するぐらいしか無いのは無かろうか。
本質的にはそうかもしれませんが、次善の策として、rootで動き基本的にキーボードやディスプレイを握るXサーバが何らかの手立てを準備しても良いかと思います。まあ、後段にも近いですが、ローカル、すなわちハードを触れる環境であれば間にロガーとかプロキシ的なハードを噛ますことが可能であり、OS含めソフトが絶対的権限を持ちえないともいえます。UNIXはそういう観点に近かった気がします。
「トラップできない操作が存在するということを前提にした仕組みを、そのような操作が存在しない環境に導入しようとすると難しいよね。」という話だと思うのですが「そうですね」以外にどう答えようもないので、あれこれ雑談するためには例えば、それが役立たない状況を想定してみるとかしないと続かないと思うのだけど、それでは駄目なの？
まず、WindowsはNTの時代から上記４点は実現されています。そして、この話はオレンジブックなどにも載っているセキュリティの基礎、教科書レベルの話であって、今更議論するような内容ではありません。
Xは明らかに脆弱で時代遅れです。誤魔化すのはやめましょう。別にXやLinuxを攻撃する意図はありません。事実を受け入れましょうと言っているだけです。我々にできることは現状を過信せず、Waylandのような新しいプロジェクトが頓挫しないようできることをするだけです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
スクリーンロッカーで何が守れるのか (スコア:2)
それには、攻撃プログラムを起動できる脆弱性か、Xサーバーに許可なく遠隔で接続させうる脆弱性が必要になると思います。
そのような脆弱性が有るなら、スクリーンロッカーをいじらずとも、何でも可能な状態なのではないでしょうか。
Re: (スコア:0)
スクリーンロックを解除するためにはパスワード入力が必要です。
確かに何らかのプログラムが必要ですが、単に何らかのプログラムを起動しただけではパスワードを知ることは出来ません。
しかしロック画面を表示することで自然な形でパスワードを収集出来ます。
また一般ユーザ権限のプロセスでも、管理者ユーザのロック画面などに偽装することで、管理者権限を得ることが可能かもしれませんし、
共用PCならばログイン画面に偽装して他ユーザのパスワードを収集することも可能かもしれません。
＃そういった画面に偽装しなくても騙される人はいるからパスワード収集は可能ですが、偽装できればさらに効率は上がるでしょう。
＃ブラウザのアドレスバーやダイアログの偽装とかも類型と言えるかな？
NT系でCTRL+ALT+DELキーが必要なのは、これがプロセスによりトラップするなどで無効化できないものであるからです。
＃ということをユーザが知らなければ意味がないのですけれどね。
Re:スクリーンロッカーで何が守れるのか (スコア:1)
異なる機能のものを比較しても意味があるとは思えません。「NT系でCTRL+ALT+DELキーが必要」というのはローカルの話で、X は基本的にネットワークベースです。
Windows であってもリモートデスクトップ越しにスクリーンロッカーに見えるものを解除する時、Ctrl + Alt + End を受け取ったローカル側のプロセスが、正しいリモートデスクトップなのか、そういった画面に偽装したパスワード収集ソフトなのかを判別できないのではないでしょうか。
Re:スクリーンロッカーで何が守れるのか (スコア:1)
windowsはCtrl+Alt+Delのトラップを無効化してるので
偽のスクリーンロックを見破れますって話でしょ
Re: (スコア:0)
ええとですね、2015年の今現在Xをネットワークに生で流すことは推奨されていないのです。
XはデフォルトではUnixDomainしかlistenせず、tcp:6000を開けるならsshのポートフォワードを使うことが強く推奨されています。
Xはネットワークベース？古き良き時代はそうでした。今はローカルのレンダラですよ。
Re:スクリーンロッカーで何が守れるのか (スコア:3)
ロックされているように見える画面に対し、パスワードを入力する前に、正しい相手かどうかの識別を CTRL-ALT-DEL という特定のキーコンビネーションに反応するかどうかで判断する、というのはローカル OS などキーボードに対し絶対的な権限をもつものの設計としてしか意味がないのでは、という話です。Windows のリモートデスクトップにせよ、X にせよ、（X サーバと通信する）クライアントプロセスがロック解除のためのパスワードを処理するならば、ローカルのキーボードに頼ることはそもそもできないでしょう。
Wayland で UI を握って云々という話は、CTRL-ALT-DEL や Windows キー+電源ボタン並になることはあっても、本質的な解決とは思えません。
そもそも、問題の本質は、ユーザである人間が、パスワードを教えて良い正しいプロセスかどうかを「認証」するにはどうしたら良いか、ということです（別に認証が正しくてもキーロガー等で「盗聴」されているかも、という問題もありますが）。（ネットワークや多様なハードウェアを想定した）ハードウェアの仮想化、例えば Windows や iOS 上のアプリケーションから利用する、そもそも物理キーボードがない場合などを考えると、抜本的にはパスワードを使わずにGoogle Authenticator [wikipedia.org]などで TOTP 認証にするなど、別に「鍵」を用意するぐらいしか無いのは無かろうか。
Re: (スコア:0)
本質的にはそうかもしれませんが、次善の策として、rootで動き基本的にキーボードやディスプレイを握るXサーバが何らかの手立てを準備しても良いかと思います。
まあ、後段にも近いですが、ローカル、すなわちハードを触れる環境であれば間にロガーとかプロキシ的なハードを噛ますことが可能であり、OS含めソフトが絶対的権限を持ちえないともいえます。
UNIXはそういう観点に近かった気がします。
Re:スクリーンロッカーで何が守れるのか (スコア:2)
Re:スクリーンロッカーで何が守れるのか (スコア:1)
「トラップできない操作が存在するということを前提にした仕組みを、そのような操作が存在しない環境に導入しようとすると難しいよね。」
という話だと思うのですが「そうですね」以外にどう答えようもないので、あれこれ雑談するためには例えば、それが役立たない状況を想定してみるとかしないと続かないと思うのだけど、それでは駄目なの？
Re:スクリーンロッカーで何が守れるのか (スコア:1)
キー入力や画面の内容をキャプチャされない、特権モードのウィンドウがあればいいのかな。
ただ、それにはユーザが以下の事を理解して実行する必要があり、かなりの教育が必要になりそうですね。
1. パスワードを要求するウィンドウは「特権モード」である必要がある。
2. 特権モードでウィンドウを作成できるのは、あらかじめ設定されたプログラムだけ。
3. ウィンドウが特権モードかどうかは、ユーザが「特権を確認する操作」を行ない判断できる。
4. ユーザはスクリーンロッカーなどの、パスワードを要求するウィンドウには必ず「特権を確認する操作」を行なった上で、パスワードを入力しなければならない。
(パスワードを守ることで守られる物は何か、という問題もあります。
攻撃プログラムを実行された時点で、パスワードで守りたかった物があらかた盗られている可能性もあります。)
Re: (スコア:0)
Re:スクリーンロッカーで何が守れるのか (スコア:1)
そういったキーロガー的なプロセスにもフックされない「特権モード」を新に作れば解決するのかな、と思った次第です。
「特権モード」ウィンドウに対するイベントはキャプチャできないので、パスワードは盗れません。
「特権モード」ウィンドウのふりをしても、ユーザが「特権を確認する操作」をした時点でバレます。
Re: (スコア:0)
まず、WindowsはNTの時代から上記４点は実現されています。
そして、この話はオレンジブックなどにも載っているセキュリティの基礎、教科書レベルの話であって、今更議論するような内容ではありません。
Xは明らかに脆弱で時代遅れです。誤魔化すのはやめましょう。別にXやLinuxを攻撃する意図はありません。事実を受け入れましょうと言っているだけです。
我々にできることは現状を過信せず、Waylandのような新しいプロジェクトが頓挫しないようできることをするだけです。
Re:スクリーンロッカーで何が守れるのか (スコア:1)
「特権を確認する操作」として、Ctrl+Alt+Del があるという事でしょうか。
ユーザが理解して使っている限り、いい機能だと思います。
ただ「特権を確認する操作」は、本質的に難しいものだと思います。
パスワードを入力できるほど信用できるプログラムと、信用できないプログラムを、信用できないプログラムを起動してから見分けるという事ですから。
Ctrl+Alt+Del のような機能を、スクリーンロックだけでなく端末で sudo にパスワードを聞かれた時などにも適用しなければいけません。
私は X を擁護しているのではありません。
現状、信用できないプログラムの実行や接続を許した時点で、もう駄目だろうと思うだけです。
Xが時代遅れなのは事実でしょうね。Waylandなどには期待しています。