アカウント名:
パスワード:
スクリーンロックを解除するためにはパスワード入力が必要です。確かに何らかのプログラムが必要ですが、単に何らかのプログラムを起動しただけではパスワードを知ることは出来ません。しかしロック画面を表示することで自然な形でパスワードを収集出来ます。また一般ユーザ権限のプロセスでも、管理者ユーザのロック画面などに偽装することで、管理者権限を得ることが可能かもしれませんし、共用PCならばログイン画面に偽装して他ユーザのパスワードを収集することも可能かもしれません。＃そういった画面に偽装しなくても騙される人はいるからパスワード収集は可能ですが、偽装できればさらに効率は上がるでしょう。＃ブラウザのアドレスバーやダイアログの偽装とかも類型と言えるかな？
NT系でCTRL+ALT+DELキーが必要なのは、これがプロセスによりトラップするなどで無効化できないものであるからです。＃ということをユーザが知らなければ意味がないのですけれどね。
異なる機能のものを比較しても意味があるとは思えません。「NT系でCTRL+ALT+DELキーが必要」というのはローカルの話で、X は基本的にネットワークベースです。
Windows であってもリモートデスクトップ越しにスクリーンロッカーに見えるものを解除する時、Ctrl + Alt + End を受け取ったローカル側のプロセスが、正しいリモートデスクトップなのか、そういった画面に偽装したパスワード収集ソフトなのかを判別できないのではないでしょうか。
ええとですね、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はそういう観点に近かった気がします。
「トラップできない操作が存在するということを前提にした仕組みを、そのような操作が存在しない環境に導入しようとすると難しいよね。」という話だと思うのですが「そうですね」以外にどう答えようもないので、あれこれ雑談するためには例えば、それが役立たない状況を想定してみるとかしないと続かないと思うのだけど、それでは駄目なの？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
スクリーンロッカーで何が守れるのか (スコア:2)
それには、攻撃プログラムを起動できる脆弱性か、Xサーバーに許可なく遠隔で接続させうる脆弱性が必要になると思います。
そのような脆弱性が有るなら、スクリーンロッカーをいじらずとも、何でも可能な状態なのではないでしょうか。
Re: (スコア:0)
スクリーンロックを解除するためにはパスワード入力が必要です。
確かに何らかのプログラムが必要ですが、単に何らかのプログラムを起動しただけではパスワードを知ることは出来ません。
しかしロック画面を表示することで自然な形でパスワードを収集出来ます。
また一般ユーザ権限のプロセスでも、管理者ユーザのロック画面などに偽装することで、管理者権限を得ることが可能かもしれませんし、
共用PCならばログイン画面に偽装して他ユーザのパスワードを収集することも可能かもしれません。
＃そういった画面に偽装しなくても騙される人はいるからパスワード収集は可能ですが、偽装できればさらに効率は上がるでしょう。
＃ブラウザのアドレスバーやダイアログの偽装とかも類型と言えるかな？
NT系でCTRL+ALT+DELキーが必要なのは、これがプロセスによりトラップするなどで無効化できないものであるからです。
＃ということをユーザが知らなければ意味がないのですけれどね。
Re: (スコア:1)
異なる機能のものを比較しても意味があるとは思えません。「NT系でCTRL+ALT+DELキーが必要」というのはローカルの話で、X は基本的にネットワークベースです。
Windows であってもリモートデスクトップ越しにスクリーンロッカーに見えるものを解除する時、Ctrl + Alt + End を受け取ったローカル側のプロセスが、正しいリモートデスクトップなのか、そういった画面に偽装したパスワード収集ソフトなのかを判別できないのではないでしょうか。
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)
「トラップできない操作が存在するということを前提にした仕組みを、そのような操作が存在しない環境に導入しようとすると難しいよね。」
という話だと思うのですが「そうですね」以外にどう答えようもないので、あれこれ雑談するためには例えば、それが役立たない状況を想定してみるとかしないと続かないと思うのだけど、それでは駄目なの？