デタッチスクリーンセッションでルートシェルを実行したままにしておくのは安全ですか?


20

私は、分離されたスクリーンセッション内でルートシェルを実行したままにすることのセキュリティに興味があります。私は通常これをしません。

ルート以外のユーザーアカウントが侵害される可能性(パスワードの公開、sshキーの侵害など)の他に、心配する必要がある、パスワードで保護された分離された画面セッションへのエントリの他のベクトルがありますセッションは不活性と見なされますか?


私はそれを知らないので、これは答えではありませんが、あなたが言ったようにすることと仕事を辞めることとの間に違いはないと思いますsudo
プネヘヘ

7
@phuneheheジョブが完了するとsudo、真のルートシェルが開いたままで非アクティブになるため、違いがあります。
マイケル

回答:


5

「ルート以外のユーザーアカウントが侵害される可能性は別として」それはかなり大きい可能性があるため、これはセキュリティ上の問題だと思います。

しかし、それ以外にもリスクが増加しています。たとえば、スクリーンソケットディレクトリ(/var/run/screen私のシステムで/tmpは使用されますが、時々使用されます)のアクセス許可を変更できる理論上の悪用に自分自身を開放しました。そのエクスプロイトには、ルートを取得するためのパスがあります。

sudoを実行するのではなく、各コマンドで使用するように自分を訓練できる場合、他の利点がありますsudo su -。アクションをログに記録します(リモートでログを記録している場合を除き、セキュリティを大幅に向上させることはありませんが、実行した内容を追跡できます)。また、完全に特権のあるセッションに切り替えるのではなく、コマンドごとに意図的なエスカレーションを要求することで、事故の防止に役立ちます。


1
そのようなエクスプロイトは現在知られていませんが、私は画面でルートシェルを開いたままにしないつもりです。ユーザーアカウントに対するリスクはそのままで十分です。ありがとう。
マイケル

-1ファイルのアクセス権を変更できるエクスプロイトがある場合、実行中の画面をハッキングする必要はありません。私はシステムで何でもできます。
-Let_Me_Be

@Let_Me_Be -それはに依存している、あなたが利用するファイルのパーミッションを変更することができます。特定の階層の下では、いくつかの特定のことしかできないかもしれません。それはそれほど大げさではありません。
mattdm

画面自体には大きな攻撃対象があります。完全な攻撃を示すことはできませんが、明らかな弱点があります。
ジル 'SO-悪であるのをやめる'

私が間違っている場合、私を修正しますが、画面アプリは、シェルセッションを介して(システムコンソールで直接、またはsshセッションを介して)インターフェイスされます。私が知っている限り、それ自体はネットワークプロトコルではありません。したがって、sshセッションまたはターミナルセッションと同じくらい安全です。一部がsshセッションまたは物理マシンにアクセスできる場合、すべてのベットはオフになります。ユーザーアカウントで任意の種類のコマンドラインにアクセスするのに十分なアクセス権がある場合は、とにかくコンピューターのセキュリティを破棄することもできます。
同期されていない

10

スクリーンセッションにルートシェル(デタッチされているかどうか、パスワードで保護されているかどうか)があり、screen実行可能ファイルがsetxidでない場合、特権を取得した攻撃者はそのシェルでコマンドを実行できます。他に何もなければ、彼らはスクリーンプロセスを追跡することによってそれを行うことができます。

screenがsetuidまたはsetgidであり、セッションが切り離されてパスワードで保護されている場合、原則として、そのシェルでコマンドを実行するために画面のパスワードを取得します。この原則が成り立つ場合、アカウントを侵害しただけの誰かがトロイの木馬を置き、パスワードの入力を待つ必要があります。ただし、攻撃対象領域(つまり、バグや構成の誤りが原因で問題が発生する可能性のある場所の数)は不快なほど大きくなります。基本的なシステムセキュリティ機能に加えて、次のことを信頼しています。

  • パスワードチェックを正しく行うための画面。
  • 他の手段によるセッションへのアクセスを防ぐための画面。
  • OSアクセス制御メカニズムを適切に使用するための画面(たとえば、パイプのアクセス許可)。
  • カーネルがptraceセキュリティチェックを正しく実行する(これは脆弱性の頻繁な原因です)。
  • 実行中のシェルはバカなことは何もしません。
  • あなたを噛まない他の機能。

「あなたを噛まない他の機能」:ええ、それはあいまいです。しかし、それは常にセキュリティの問題です。これを単なる希望的観測として却下したくなるかもしれませんが、本当にすべてを考えましたか?例えば…

端末デバイスに書き込むことができる限り、そのシェルの入力にデータを注入できます。私のマシンの画面のデフォルト設定の下:

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

これ␛]lfoobar␛lにより、シェルの入力ストリームに挿入されます。\ekアプリケーション(または端末デバイスに書き込むことができるもの)がウィンドウタイトルを設定し(スクリーンマニュアルの「ウィンドウの命名」セクションを参照)、\e[21tアプリケーションの標準入力で端末にタイトルを報告させる制御シーケンスです( screenはこのシーケンスを文書化しませんが、それを実装します; xterm制御シーケンスリストCSI Ps ; Ps ; Ps ; tで見つけることができます実際、少なくとも画面4.0.3では、報告されたタイトルからすべての制御文字が取り除かれるため、シェルは(仮定は編集コマンドにバインドされていない)、改行はありません。したがって、攻撃者は実際にそのようにコマンドを実行することはできませんが、次のようなコマンドを詰め込むことができますlfoobar␛]chmod u+s /bin/sh 多くのスペースと見かけのプロンプトが続きます。

Screenは、他の同様の危険な制御シーケンスをいくつか実装していますが、脆弱性に対する潜在的な可能性はわかりません。しかし、スクリーンセッションパスワードによって提供される保護がそれほど優れていないことがおわかりいただけると思います。sudoなどの専用のセキュリティツールは、脆弱性を持つ可能性がはるかに低いです。


+1すばらしい答え。時間をかけてすべて説明してくれてありがとう。
マイケル

1

画面によって作成されたパイプは所有者のみがアクセスできるため、これはセキュリティ上の問題ではありません。


5
文章の最初の部分で「あるべき」を意味する「are」を使用しました。仮定をする習慣を身につけないようにしましょう。
シャドゥール

1
あれ?画面によって作成されたパイプは、所有者のみがアクセスできます(手動でchmodしない場合)。
-Let_Me_Be
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.