アカウント名:
パスワード:
X Windowなんてまともに使ったのはもう20年以上前だ。GUIが必要な時はvncで繋いでた。
VNCの先ではXが動いていたんじゃないですかね？
それはいくらなんでも無駄すぎるのでWindows Serverとかじゃね? それにしたってXRDPとかあるし
WindowsからLinuxを使うときにXvnc使うのは良く有る事だった。
LinuxのGUI環境どれでも確実に動くのがそれしか無いですし。
xrdp ってXにRDPプロトコルでアクセスさせるものですよ。Win-Win にわざわざ VNC を使った、という話でも無い限りXはどちらかで使われてます。
今、見捨てられようとしているのは、Xのプロトコルではなく「X.Org Server」と言うかつてメインストリームだった一つの実装でしょ。X自体はまだまだ現役。
違うでしょ。プロトコルが刷新されないから実装が死んでいく。ゾンビを生み出している元凶。認証も秘匿通信もない規格なんか現代では使い物にならないよ。外付けでdbusだとかVNCだとか作ったので何とか機能だけはなんとか使えるレベルだけど。Waylandができたら移行すればいいんじゃないですかね、Windowsに。
Win32 API「おっそうだな」
ダークモードAPIの正式サポートまだ?
WinUI 3を待ってね。
Xのネットワーク透過性の高さは利点と見なせない時期のが長いと思うけど、ネットワーク透過性高いから通信をsshトンネルできるんじゃないっけ。
sshトンネルで十分だと思ってることがダメなのです。Xが担っている情報の重要性からして、もっと中間者攻撃に強い実装にすべきです。
マジかーよのなかのAWSとかで動いてるサービス類はもうサインアップできないな
問題なのはXとsshの間が別プロセスなのに認証機構が何もないことだよ。
正直レベルについていけてないんだけどsshでbash起動するのはそれぞれ別プロセスだけどssh経由の時は追加の認証を入れてますで合ってる？
ssh上のbashは親プロセスが子プロセスの標準入出力をガッツリ掴んでいるけど、Xの転送はsshで開いたソケットをディスプレイ変数経由で通知したあとは、普通のソケット通信(大抵はローカル)で改めて無認証に接続しているだけ。環境変数に干渉されたりsshで開いているソケットにソケットを被せられたり……は無くはないけど難しいか。多分一番懸念すべきは、横からソケットに繋がれる事だと思う。横(同じホスト内の攻撃者のアカウント)からそのX転送をディスプレイ指定してプログラム立ち上げると、攻撃者の用意した偽画面を出すアプリが標的の転送中のXウィンドウとして動作してしまうんじゃないかね。Xのプロトコル上で取れるデータは取られるし、偽のパスワード入力画面出されて入力しちゃうとアウト。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
vnc (スコア:0)
X Windowなんてまともに使ったのはもう20年以上前だ。GUIが必要な時はvncで繋いでた。
Re: (スコア:0)
VNCの先ではXが動いていたんじゃないですかね？
Re: (スコア:0)
それはいくらなんでも無駄すぎるのでWindows Serverとかじゃね? それにしたってXRDPとかあるし
Re: (スコア:0)
WindowsからLinuxを使うときにXvnc使うのは良く有る事だった。
Re: (スコア:0)
LinuxのGUI環境どれでも確実に動くのがそれしか無いですし。
Re: (スコア:0)
xrdp ってXにRDPプロトコルでアクセスさせるものですよ。
Win-Win にわざわざ VNC を使った、という話でも無い限りXはどちらかで使われてます。
Re: (スコア:0)
今、見捨てられようとしているのは、Xのプロトコルではなく「X.Org Server」と言うかつてメインストリームだった一つの実装でしょ。
X自体はまだまだ現役。
Re:vnc (スコア:1)
違うでしょ。
プロトコルが刷新されないから実装が死んでいく。ゾンビを生み出している元凶。
認証も秘匿通信もない規格なんか現代では使い物にならないよ。
外付けでdbusだとかVNCだとか作ったので何とか機能だけはなんとか使えるレベルだけど。
Waylandができたら移行すればいいんじゃないですかね、Windowsに。
Re: (スコア:0)
Win32 API「おっそうだな」
Re: (スコア:0)
Re: (スコア:0)
ダークモードAPIの正式サポートまだ?
Re: (スコア:0)
WinUI 3を待ってね。
Re: (スコア:0)
Xのネットワーク透過性の高さは利点と見なせない時期のが長いと思うけど、
ネットワーク透過性高いから通信をsshトンネルできるんじゃないっけ。
Re: (スコア:0)
sshトンネルで十分だと思ってることがダメなのです。
Xが担っている情報の重要性からして、もっと中間者攻撃に強い実装にすべきです。
Re: (スコア:0)
マジかー
よのなかのAWSとかで動いてるサービス類はもうサインアップできないな
Re: (スコア:0)
問題なのはXとsshの間が別プロセスなのに認証機構が何もないことだよ。
Re: (スコア:0)
正直レベルについていけてないんだけど
sshでbash起動するのはそれぞれ別プロセスだけどssh経由の時は追加の認証を入れてますで合ってる？
Re: (スコア:0)
ssh上のbashは親プロセスが子プロセスの標準入出力をガッツリ掴んでいるけど、
Xの転送はsshで開いたソケットをディスプレイ変数経由で通知したあとは、
普通のソケット通信(大抵はローカル)で改めて無認証に接続しているだけ。
環境変数に干渉されたりsshで開いているソケットにソケットを被せられたり…
…は無くはないけど難しいか。多分一番懸念すべきは、横からソケットに繋がれる事だと思う。
横(同じホスト内の攻撃者のアカウント)からそのX転送をディスプレイ指定してプログラム立ち上げると、
攻撃者の用意した偽画面を出すアプリが標的の転送中のXウィンドウとして動作してしまうんじゃないかね。
Xのプロトコル上で取れるデータは取られるし、偽のパスワード入力画面出されて入力しちゃうとアウト。