確かに xhost を設定した覚えは無いですが、確認したところ % xhost access control enabled, only authorized clients can connect INET:192.168.0.11 (←自分のIP) INET:localhost LOCAL:となりましたが、自分で使うのだから特におかしくはないと思いますが。
ところで元の Why screen lockers on X11 cannot be secure には
While I personally disagree, it just doesn’t hold for X11. If only clients of one user were connected to the X server one could say so. But X11 allows clients from other users and even remote clients.
いまどき誰が xhost + させるのか (スコア:0)
1980年代はXサーバーにXのクライアントをたくさんぶら下げて使うとか、流行りましたねぇ。今でもXming [osdn.jp]とかもあるようですが。脆弱性? いまどき xhost + しなきゃいいんじゃないの?
それとも、xhost + させて他人に使わさせているような UNIX機を、今回の指摘が問題になるようなクリティカルな用途で使うものかね?
そもそも、XだのKDEが無けりゃ操作できないようなド素人にサーバーを管理させている時点でセキュリティー的に安全じゃないだろうけど。そういう人間はおとなしく自分専用のマシンでOpenOffice + Firefox + Thunderbird 程度を使っとけばいいんじゃないの?
Re: (スコア:1)
なんかずれてる。
1980年代はXサーバーにXのクライアントをたくさんぶら下げて使うとか、流行りましたねぇ。
今でもアプリ(Xクライアント)は複数使うのが普通ですが。
まあ、クライアントじゃなくホストなんでしょうけど。
それとも、xhost + させて他人に使わさせているような
普通それは自分で使うためにしてると思うけど。
これはxhostの様に別プロセス(アプリ)経由でなければ端末たるXサーバに働きかける手段がないってことかと。
せっかくUIデバイス握ってるのに。
Re: (スコア:0)
確かに xhost を設定した覚えは無いですが、確認したところ
% xhost
access control enabled, only authorized clients can connect
INET:192.168.0.11 (←自分のIP)
INET:localhost
LOCAL:となりましたが、自分で使うのだから特におかしくはないと思いますが。
ところで元の Why screen lockers on X11 cannot be secure には
とあって、Xは1台の
Re:いまどき誰が xhost + させるのか (スコア:0)
違う要素がかぶってる気がするな。
一つはXサーバが走ってるマシン(あなたはそれと物理的につながったディスプレイやマウス・キーボードで操作している)にリモートからログインしてる別のユーザがいて、さらにXサーバの設定が、
INET:192.168.0.11 (←自分のIP)
INET:localhost
これだとそのログインしてる別ユーザは自由にそのマシンのXサーバにアクセスできる=つながってるディスプレイになんでも自由に表示でき、表示された内容を取得できる状態。
xhostによる制御にはユーザの概念がないので。
ただ、ウィンドウマネージャがあるので、そっちの制御を回避したりオーバーライドできるのかまでは分からない。
これはWindowsでいうとリモートアシスタントが有効な状態に近い。
ただ、普通はxhostじゃなくxauthにより制御されてて、それだとそうはいかない。
もう一つはGUIをOSがつかんではいないし、Xサーバ自身が認証機構を持たず、rootで走るクライアントプロセスが認証してログイン等する方式である点。
先のように、もともとXサーバ自身はユーザ単位の認証機構を持ってないので、一般プロセスでの偽装が容易であるという点。
Xの場合はWebのようにフィッシングのような危険性がある。ただし、そのためには何らかのプロセス(マルウェア)を走らす必要がある。
この点、OSとしてGUIをつかんでいるWindowsはctrl+alt+delとかUACとかいった機構で保護を図ろうとしている。