Ubuntuのシステムプロンプトは私のパスワードを偽装できませんか？
Ubuntuが次のウィンドウを表示することがあります。
このウィンドウは、自動更新などの実行中のバックグラウンドプロセスや、バグをCanonicalに報告するプロセスが原因で発生する可能性があります。
これらはバックグラウンドプロセスであるため、システムがパスワードを要求することを期待していた状況で、自分が実行したアクションに応答して最初のウィンドウが表示されません。この意味は：
ユーザーの観点からは、プロンプトがオペレーティングシステムからのものであるという保証はありません。ウィンドウを表示するための限られた権限しか持たず、パスワードを要求することでマシン全体に無制限にアクセスできる悪意のあるプログラムである可能性があります。
ユーザーに定期的にパスワードを要求することにより、システムはユーザーに、アプリケーションが要求するたびにシステムパスワードを与えることは完全に自然なことであることを教えます。
私の質問は：
一般的なLinuxまたはUbuntuに、システムと同じように見えるダイアログをアプリケーションが表示してパスワードを要求するのを防ぐ安全メカニズムはありますか？
このようなウィンドウは、ユーザーの安全性を高めるためにどのように設計すべきですか？ Windowsに似たシステムを実装しないのはなぜですか Ctrl+Alt+Del ログオン時 ？
あなたの主張はすべて適切であり、正しいですが、私たちがそれに憤慨する前に、Linuxセキュリティモデルがどのように機能し、どのように設計されているかを思い出す必要があります。
Linuxセキュリティモデルは、マルチユーザーの端末専用サーバーまたはSSHサーバーを念頭に置いて設計されていることに注意してください。 Windowsはエンドユーザーワークステーションを念頭に置いて設計されています（ただし、最近の世代のWindowsはよりターミナルフレンドリーであると聞きました）。特に、Linuxの規則はアプリをユーザーにサンドボックス化するのに適していますが、Windowsでは重要なものはすべてシステムとして実行されますが、Linux GUI（Xサーバー）はセキュリティを弱め、Windows GUIにはUACが組み込まれています。基本的に、Linuxはサーバーであり、常にワークステーションが2番目ですが、Windowsはその逆です。
セキュリティモデル
「OS」（つまりカーネル）に関する限り、7つのttyコンソールと任意の数のSSH接続（別名「ログインセッション」）があります。ubuntuには、GUIを自動起動するスクリプトが付属していることがよくありますtty7セッションですが、カーネルにとっては別のアプリケーションです。
ログインセッションとユーザーアカウントは互いに適切にサンドボックス化されていますが、Linuxはユーザーを自分自身から保護する必要がないというセキュリティの考え方を取り入れています。このセキュリティモデルでは、アカウントがマルウェアに感染した場合、それは失われた原因ですが、システム全体を保護するために他のアカウントから隔離する必要があります。
たとえば、LinuxアプリはApacheやftpのような低い権限のユーザーを作成する傾向があり、rootを実行する必要がないときに実行されます。攻撃者が実行中のApacheプロセスを制御できた場合、他のApacheプロセスをマックアップできますが、ftpプロセスにジャンプするのに問題があります。
ここでは、Windowsが根本的に異なるアプローチを取っていることに注意してください。主に、すべての重要なものが常にシステムとして実行されるという慣例に基づいています。 Linuxの悪意のあるサービスは、システムとして実行されている悪意のあるプロセスよりも悪意のある行為を行う範囲が少ないため、Windows needs管理者権限を持つユーザーを「自分自身」から保護するために特別な努力をする必要があります。
セキュリティのために設計されていないGUI環境とXサーバーは、このセキュリティモデルにレンチを投げ込みます。
Gnome gksudo対Windows UAC、およびキーロガー
Windowsでは、ユーザープロセスが特権の昇格を要求すると、カーネルは特別な保護されたプロンプトをスローし、そのメモリとキーボード/マウスバスがデスクトップ環境の他の部分から分離されます。 GUIがOSに組み込まれているため、これを行うことができます。 Linuxでは、GUI（Xサーバー）は単なる別のアプリケーションであるため、パスワードプロンプトは、それらを呼び出したプロセスに属し、ユーザーとして実行され、メモリのアクセス許可と入力バスを他のすべてのウィンドウおよびプロセスと共有します。
Rootプロンプトは、すでにrootである必要があるか、Xサーバーを完全に再設計する必要があるため、キーボードをロックするという素晴らしいUACのことはできません（以下のWaylandを参照）。この場合、GUIをカーネルから分離することのマイナス面であるcatch-22。しかし、少なくともLinuxのセキュリティモデルに準拠している。
同じGUIセッションでユーザーとして実行されているパスワードプロンプトと他のプロセスの間にサンドボックスを追加することにより、これを制限するためにセキュリティモデルを修正する場合、非常に多くのことを書き直す必要があります。少なくとも、カーネルはプロンプトを作成できるようにGUIを認識する必要があります（今日は当てはまりません）。もう1つの主な例は、GUIセッションのすべてのプロセスがキーボードバスを共有することです。
キーロガーを作成してからいくつかのキーを押すのを見てください別のウィンドウで：
➜ ~ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech K400 Plus id=9 [slave pointer (2)]
⎜ ↳ ETPS/2 Elantech Touchpad id=13 [slave pointer (2)]
➜ ~ xinput test 9
key release 36
key press 44
hkey release 44
key press 40
ekey release 40
key press 33
lkey release 33
key press 33
lkey press 39
okey release 33
key release 39
key press 66
key press 31
別のプロセスのプロンプトまたはターミナルでパスワードを盗聴し、それ自体でSudoを呼び出すことができるように実行されているプロセス（これは「ユーザーを保護する必要がない」という考え方から直接続く）なので、パスワードプロンプトのセキュリティを強化しても意味がありません私たちは根本的にセキュリティモデルを変更し、あらゆる種類の大規模な書き換えを行います。
（Gnomeは、ロック画面のキーボードバスと「ユーザーの切り替え」を介した新しいセッションを少なくともサンドボックス化しているように見えるので、そこで入力したものがセッションのキーボードバスに表示されないことに注意してください）
ウェイランド
Waylandは、X11の置き換えを目的とした新しいプロトコルです。クライアントアプリケーションをロックダウンして、情報を盗んだり、ウィンドウの外に影響を与えたりできないようにします。クライアントが外部の外部と相互に通信できる唯一の方法IPC=すべてを制御するコンポジターを通過することです。ただし、これは根本的な問題を修正せず、単にニーズを変更します合成者への信頼のため。
仮想化とコンテナー
クラウドテクノロジーを使用している場合は、おそらく「Dockerが答えです!!」と言って上下にジャンプしています。確かに、あなたのためのブラウニーポイント。 Docker自体はセキュリティの強化を意図したものではありませんが（@SvenSlootwegに感謝）、現在のLinuxアーキテクチャと互換性のあるフォワードとしてコンテナー化や仮想化を使用することを示しています。
プロセス間分離を念頭に置いて構築された2つの注目すべきLinuxディストリビューション：
Qubes OSこれは、仕事、銀行、Webブラウジングなどの「セキュリティドメイン」に分離された複数のVM内でユーザーレベルのアプリを実行します。
Androidこれは、各アプリを個別の低特権ユーザーとしてインストールして実行することで、アプリ間でプロセスレベルの分離とファイルシステムの分離（各アプリは独自のホームディレクトリに限定されます）を実現します。
ボトムライン：エンドユーザーの観点から見ると、LinuxがWindowsと同じように動作することを期待することは不合理ではありませんが、これは、その方法について少し理解する必要があるケースの1つです。基礎となるシステムが機能し、そのように設計された理由。パスワードプロンプトの実装を変更するだけでは、それがユーザーが所有するプロセスによって所有されている限り、何も起こりません。 LinuxがシングルユーザーGUIワークステーションのコンテキストでWindowsと同じセキュリティ動作を得るには、OSの大幅な再設計が必要になるため、起こりそうにありませんが、Dockerなどの方法により、より多くのLinux-ネイティブの方法。
この場合の重要な違いは、Linuxは低レベルでマルチユーザーサーバーとして設計されており、ユーザーが自分からユーザーを保護しないことを決定するのに対し、Windowsはシングルユーザーワークステーションとして設計されていることです。そのため、ログインセッション内でプロセス間保護を行う必要があります。また、WindowsではGUIがOSの一部であるのに対し、LinuxではGUIがユーザーレベルのアプリケーションの1つにすぎないことも重要です。
一般的なLinuxまたはUbuntuに、システムのそれと同じように見えるダイアログをアプリケーションが表示してパスワードを要求するのを防ぐ安全メカニズムはありますか？
簡単な答え：いいえ。
ユーザーの観点からは、プロンプトがオペレーティングシステムからのものであるという保証はありません。ウィンドウを表示するための限られた権限しか持たない悪意のあるプログラムである可能性があり、パスワードを要求することで、マシン全体に無制限にアクセスできます。
悪意のあるプログラムがコンピューター上にある場合、どのプログラムがダイアログを表示しているかは関係ありません。
次の文で説明するように、それが悪意のあるプログラムであれば、ダイアログを表示する必要すらありません。正当なプログラムである場合、悪意のあるプログラムは、ウィンドウとそこで入力している内容をXサーバー環境で「監視」することができます（ターミナルの方が優れています）。
解決？
一部のプログラムが信頼できないと信じる理由がある場合は、サンドボックス化（VM以下）します。
そうでなければ、パスワードを要求しないです。このダイアログは、技術者以外のユーザーにとって便利です。セキュリティや組織の管理者などが心配な場合は、GUIパスワードクエリを表示する必要はありません。 root以外のユーザーアカウントの権限を適切に構成し（はいまたはいいえ、要求はしません）、デスクトップをrootとして使用しないでください（そのため、そして必要以上にrootを使用するのは誘惑であるためです）。
ユーザーに定期的にパスワードを要求することにより、システムはユーザーに、アプリケーションが要求するたびにシステムパスワードを与えることは完全に自然なことであることを教えます。
説明したように、彼らに尋ねないでください。管理者として、「あなたの」ユーザーは明確に定義された権限を持っているはずです。
そして、組織管理者としての自動更新について：あなたは正気ではありません:)真剣に、多くのUbuntuクライアントにランダムなタイミングでランダムなものを更新させないでください。あなたが保守およびテストしてからロールアウトする中央イメージはどうでしょうか。またはAnsibleのような他の方向のもの？
セキュリティから完全に独立しているため、更新により問題が発生する可能性があります。それが理由です。
はい、これは安全ではありません！
私は個人的に常にそのダイアログをキャンセルします。それは偽物である可能性があるのではなく、本物である可能性があるためです。
「アプリケーション」が要求したからといってエスカレートされた特権を与えることになっていますか？いいえ、そうは思いません。
システムの更新は問題ありませんが、手動で行いますが、エラー報告システムでこれが必要なのは不愉快です。悪いデザイン。
パスワードが盗まれていないことを確認する最も安全な方法は、SAKシーケンスを使用することです：alt-sysrq-k。これにより、現在のVT（X11を含む）上のすべてのプログラムが強制終了され、initにより新しいログインプロンプトが表示されます。私が知っている唯一の攻撃には、カーネルのキーマップの変更またはinit自体の侵害が含まれています。どちらの攻撃にも、すでにルート以上のアクセスが必要です。
システムの信頼度に応じて、さまざまなわずかに不完全な方法があります（XTermはX11の「排他的入力」オプションにアクセスする方法があります）。しかし、なぜシステムを信頼できないのでしょうか。
LinuxとWindowsのセキュリティモデルの主な違いは、Linuxでは、インターネットからランダムな実行可能ファイルをダウンロードして実行するだけですしないでください。 （信頼されていないLinuxアプリケーションをAndroidのようなパッケージサンドボックスにパッケージ化する取り組みはいくつかありますが、誰も使用していません。）