別々の画面セッションでルートシェルを実行しても安全ですか？

スクリーンセッションにルートシェルがあり（分離されているかパスワードで保護されているか）、実行可能screenファイルがsetxidでない場合、アクセス権を取得した攻撃者はそのシェルでコマンドを実行する可能性があります。他の方法がなければ、これを行うことができます。道絵画プロセス。

screen が setuid または setgid で、セッションが分離され、パスワードで保護されている場合、原則として、そのシェルでコマンドを実行するには画面パスワードが必要です。この原則が本当なら、単にあなたのアカウントを損なった誰かがトロイの木馬をインストールし、あなたがパスワードを入力するのを待つ必要があります。ただし、攻撃面（つまり、バグや誤った構成によって問題が発生する可能性がある場所の数）は非常に広いです。基本的なシステムセキュリティ機能に加えて、以下を信頼します。

• パスワード確認が正しいか確認する画面です。
• 他の手段を介してセッションにアクセスするのを防ぐ画面です。
• オペレーティングシステムのアクセス制御メカニズム（パイプに対する権限など）を正しく使用するための画面。
• カーネルはptraceセキュリティチェック（脆弱性の一般的な原因）を正しく実行します。
• 実行中のシェルは愚かなことをしません。
• 他のいくつかの機能はあなたを噛むことはありません。

「あなたを噛まない他の機能」：はい、それはあいまいです。しかし、常に安全上の問題があります。これがただの希望だと思うかもしれませんが、本当にそれについて考えてみましたか？例えば…

端末デバイスに書き込むことができる限り、シェルの入力にデータを注入できます。マイコンピュータ画面の基本設定では：

printf '\ekfoo\017bar\e\\' >/dev/pts/33
printf '\e[21t' >/dev/pts/33

␛]lfoobar␛lこれはシェルの入力ストリームに挿入されます。\ekアプリケーション（または端末デバイスに書き込むことができるすべて）がウィンドウのタイトルを設定できるようにする制御シーケンス（参照：画面マニュアルの「Windowsの命名」セクション）、\e[21t端末にアプリケーションの標準入力のタイトルを報告させます（Screenはこのシーケンスを文書化しませんが、実装します）CSI Ps ; Ps ; Ps ; t。xterm 制御シーケンスのリスト。実際、画面4.0.3では、レポートタイトルからすべての制御文字が削除されるため、シェルは改行なしで読み取られますlfoobar（␛]編集コマンドにバインドされていないと仮定）。したがって、攻撃者は実際にこの方法でコマンドを実行することはできませんが、コマンドのchmod u+s /bin/sh後に空白がある場合やプロンプトのように見えるなど、コマンドを追加する可能性があります。

Screenは、いくつかの他の同様のリスク制御シーケンスを実装しており、その脆弱性の可能性が何であるかわかりません。しかし、今では、スクリーンセッションパスワードが提供する保護があまり優れていないことがわかります。 sudoなどの専門的なセキュリティツールは、脆弱性がある可能性がはるかに少なくなります。