名前

       rssh - scp と sftp の両方だけ、またはその一方のみを許可する 制限付セキュアシェル

書式

       rssh -c scp|sftp-server [ options... ] [ ... ]

説明

       rssh  はホストへの  ssh(1) を使ったアクセスの制限を提供する制限付きシェルで、シェルが rssh
       に設定されたユーザには、 scp(1), sftp(1), cvs(1), rdist(1), rsync(1)  のうちの一つ以上のコ
       マンド  のみ 使用を許可する。 主に、OpenSSH (http://www.openssh.com を参照) と共に動作する
       ように意図されてはいるが、 他の実装とも共に動作するだろう。

       機密をもつシステムの管理者は、このシェルをインストールすべきである。  アクセスが制限される
       べきすべてのユーザに対し、  そのパスワードエントリを編集し、シェルが  rssh  になるようにす
       る。 例えば以下のようにする。

              luser:x:666:666::/home/luser:/usr/bin/rssh

       もし -v オプション付きで起動されたら、 rssh はバージョン番号を表示して終了する。 rssh への
       その他の引数はリモートの  ssh(1) クライアントによって指定されたものが渡される。 一般のユー
       ザはこのことをほとんど意識する必要はない。 制御を  scp(1)  または  sftp(1)  に渡すために、
       rssh  に渡される引数は、リモート側のシェルが受け取ったものを(そのまま)  使わなければならな
       い。  もし  rssh  が適合しない引数を受け取った場合には、エラーメッセージを出して終了する。
       ユーザが実行しようとしたプログラムが許可されなかった場合は  エラーメッセージを出力して終了
       する。 また、(コマンド置換のような)シェルコマンドを実行しようとした場合も エラーメッセージ
       を出力して終了する。

       rssh には設定ファイル rssh.conf(5) があり、 rssh の動きのいくつかを設定可能である。 詳細は
       man ページを参照のこと。

セキュリティ上の注意

   コマンドライン解析器
       rssh バージョン 2.2.3  の時点では、任意のコマンドの実行を引き起こす  (その結果、rssh  のセ
       キュリティをかいくぐる) ようなコマンドラインオプションを避けるために、コマンドライン全体を
       解析しなくてはならない。  ソースコードを健全にしておくため、やや熱心すぎるぐらいにコマンド
       ラインオプションをマッチングする。  実際にはこれは問題にはならないが、理論上は可能だからで
       ある。

       本当はそうではないにもかかわらず、  「安全でないコマンドラインオプションを拒否した」という
       理由で  rssh の実行を拒否されるという問題に突き当たったら、コマンドラインを次のように 変え
       てみて欲しい。 すべての短いオプションを1文字のオプションフラグで指定する (例えば、-ep の代
       わりに  -e -p)、 引数とそれぞれのオプションをスペースで区切る (例えば、-p123 の代わりに -p
       123)。 ほとんど全ての場合で、これで問題は解決する。 お分かりのとおり完全な検索はしていない
       が、 一般的に有り得るような問題は見つかっていない。

       別の解決策は、rcp,  rdist, rsync に対する完全なコマンドライン解析器を 実装しておくことがだ
       が、それはこのプロジェクトの目的でない。 実用上は、既にある解析器で十分である」 しかし、も
       しそうでない場合を見つけたのなら、詳細を rssh メーリングリストに投稿して欲しい。 rssh メー
       リングリストへの投稿に関する詳細は rssh ホームページから得ることができる。

   rssh をかいくぐることに対する安全策
       rssh は他のいくつかのプログラムと相互に作用するように設計されている。 たとえ rssh に完全に
       バグがなくても、他のプログラムの変更が  rssh  が提供している保護機能を無視する結果となり得
       る。 システム管理者、すなわちあなたにとって重要なことは、 rssh  と共に使うようにしたサービ
       スを現在のままにしておき、  それらのコマンドがユーザーに任意のコマンドの実行を許可するよう
       な 仕組みを提供していないことを確かにしておくことでである。 また、すべてのリリースの目標は
       バグがないことである一方、  完璧なものなど無い…… rssh には発見されていないバグがあるかもし
       れず、それはユーザーが rssh を無視することを許してしまうかもしれない。

       そのような脆弱性から、システムを守ることができる。 3つの基本的な方法がある。

          1. ユーザーを chroot jail に押し込める
          2. ユーザーのホームのあるファイルシステムを noexec オプション付きでマウントする
          3. 一般的なファイルパーミッションを適切に用いる

       rssh は、ユーザーを chroot jail に入れる能力をシステム管理者に与える。 詳細は rssh.conf(5)
       の man ページと、ソースコードと共に配布されている CHROOT ファイルを参照のこと。 ユーザーが
       任意のコマンドを実行できないことを確かなものにしたいなら、 chroot jail  を使用し、提供しよ
       うとしているサービスに必要なプログラム以外を そこに置かないように気をつけること。 そうすれ
       ば、標準的なコマンドの実行を防ぐことができる。

       そして、システムの実行ファイルがあるファイルシステムと、  ユーザーのファイルを分けておき、
       (もしオペレーティングシステムにその機能があれば) ユーザーのファイルのある ファイルシステム
       を  noexec  オプション付きでマウントする。  こうすれば、目的のマシンに(例えば  scp  を使っ
       て)アップロードされた プログラムが実行されるのを防ぐことができる。

       最後に、chroot   jail   の中でユーザーがアクセスできてはならないものに  ついては、標準的な
       Unix/POSIX ファイルパーミッションを使用すること。

   OpenSSH のバージョンと rssh の無視
       OpenSSH 3.5 より前では、一般的には sshd(8)  はユーザのホームディレクトリにあるファイルを解
       析しようとし、  またユーザの $HOME/.ssh ディレクトリからスタートアップスクリプトを実行しよ
       うとする。 rssh  は決してユーザーの環境(変数)を使用しようとはしない。  関連するコマンド(訳
       注:  sftp-serverなど)は、  コンパイル時に指定されたコマンドへのフルパスを指定して execv(3)
       を呼び出すことで実行される。 これはユーザの PATH  変数には依存しないし、他の環境変数にも依
       存しない。

       しかしながら、起こりうるいくつかの問題が存在する。   これは完全に  OpenSSH  プロジェクトの
       sshd の動作の仕方に原因があり、 決して rssh の欠陥ではない。たとえば、存在するであろう一つ
       の問題としては、  OpenSSH の少なくともいくつかのリリースの sshd(8) の man ページによれば、
       $HOME/.ssh/rc  ファイルに書かれているコマンドはユーザのデフォルトシェルの代わりに  /bin/sh
       によって実行される。 著者がテストに使えるシステムではこの問題は発生しない。 すなわち、コマ
       ンドはユーザに設定されたシェル  (rssh)   によって実行され、それは実行を許可しない。   しか
       し、もしこれがあなたのシステムで有効になってしまっていれば、 悪意のあるユーザは /bin/sh に
       実行されるであろう $HOME/.ssh/rc ファイルをアップロードして、 rssh  を無視することができる
       だろう。

       実際のところ、もしこの脆弱性問題が存在する(OpenSSH   の)リリースが  あるとすれば、それは古
       く、旧式のバージョンである。 最近のバージョンのOpenSSHを動かしている限りは、  私が言える範
       囲では問題ないはずだ。

       もし使っている sshd がこの攻撃に対して脆弱で ある ならば、かなり制限がかかるものの、この問
       題に対する回避方法がある。 ユーザのホームディレクトリは絶対にそのユーザが書き込めては*いけ
       ない*。  もし書き込めてしまえば、ユーザは sftp を使って(.ssh)ディレクトリの 名前を変えるか
       消すかして、あたらしい同名のディレクトリを作り、好きな       環境ファイル(訳注:       上記
       $HOME/.ssh/rc  ファイルのこと)をそこに書き込める。  ファイルのアップロードを開放するために
       は、ユーザが書き込めるディレクトリが  作成されていなければならず、ホームディレクトリのそれ
       以外の場所には 書き込めないことをユーザに承知させなければならない。

       二つ目の問題は、ユーザが環境に変数を設定できることを可能にする $HOME/.ssh/environment ファ
       イルを、sshd  がユーザの認証後に読み込むことである。   環境変数   LD_LIBRARY_PATH   または
       LD_PRELOAD を上手に操作して、任意の共有ライブラリを rssh バイナリにリンク させることによっ
       て rssh を完全に欺くことを許してしまう。 この問題を防ぐために、 rssh  は(バージョン  0.9.3
       の時点では)デフォルトでは静的にコンパイルされる。 前述の制限付きの回避方法は、この種の攻撃
       も防ぐことができる。 OpenSSH 3.5 の時点では、 sshd は PermitUserEnvironment オプションをサ
       ポートしており、これはデフォルトで  "no" に設定されている。 このオプションは、 rssh のよう
       な制限つきシェルが静的リンクの必要なしに適切に機能することを 可能にする。 rssh  バージョン
       1.0.1 の時点で、configure スクリプトは OpenSSH 3.5 が 存在するかを検出し、静的コンパイルを
       無効にする。

バグ

       ない =8^)

関連項目

       rssh.conf(5), sshd(8), ssh(1), scp(1), sftp(1)