Linux のログイン制限

ログイン戦略

ある日、マルチユーザー Linux システムのセキュリティに関して聞かれたある賢者は、「ユーザーとしてログインを許可すると、だれもが root になってしまう」と答えたという。うなずける部分も多いが、目前の妥協案が受け入れがたいこともある。そこで、危険を抑えながら信頼できない見知らぬユーザーにシェルへのログインを許可する方法について考察してみよう。

一般的に、ログインユーザーを厳しく制限したいと考える人種は2種類存在する。ひとつは、共同作業をする人々で、ふたつの別組織が共同作業を余儀なくされているケースもある。もうひとつは、セキュリティを危険にさらすだろうと確信しながらも、うさん臭い人物にシェルへのアクセスを許可したいと考えている人々だ。もし可能であれば、アクセスを与えないというのが最善策だが、与えるのであれば、パッチは必ず毎日適用したい。

信頼できないユーザーには絶対にシェルを利用させない、というのが有効な場合もあるが、ユーザーを中に入れなくてはならない場合もある。

かなり簡単な例としては、別の場所にいるリモートユーザーがログインし、同じ一連のコマンドを毎日実行しなくてはならない場合がある。この作業が簡単にスクリプト化でき、それだけが当該サーバーを利用する目的だ、と仮定すれば、シェルは絶対に必要ない。OpenSSH を使えば、ひとつの SSH キーに一連の命令を適用することができる。

SSH キーの入力終了後、以下のオプションを付加する。

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="~/bin/script.sh"

これは、キーを使うすべての SSH 接続に対して、事実上の制限を加え、参照されるスクリプトしか実行できなくする。たとえば、これを Web サーバーを再起動する「setuid」スクリプトにすることもできる。OpenSSH が command= テキストのいかなるバリエーションでも拒否するため、これはかなり安全だ。このキーを持っているユーザーは、明示的に許可されたコマンドしか実行できなくなる。

これと、場合によってはしゃれた Web ベースのツールや cron ジョブ以外となると選択肢はあまり残らない。ユーザーは、とにかくログインして作業をするしかないときもあり、そのような場合には、やらなくてはならない仕事が用意されている。

常に最新の状態になるようパッチをあてておくことは言うまでもない。ただ、ここでは「とにかく自動化せよ」とだけ言っておき、その部分にはあまり深く踏み込まないでおく。マシンのセキュリティ確保はまったく別の問題だが、検討すべき点をいくつか指摘する。

未知の攻撃から身を守るための第一防衛線が、SELinux（Security-Enhanced Linux）を有効にすることだ。

SELinux は、だれかが悪用を試みる前に、既知のセキュリティホールに対処することが要求される「アップデート」の手段を執るだけでなく、バッファオーバーフローも防ぐことができる。SELinux は大幅に改善されたアクセスシステムを提供しており、プログラムの運用に不要なものへのアクセスは制限する。これとオーバーフロー防止機能を組み合わせると、Linux システムに対して危害を加えることは相当難しくなる。

さらに、マルチユーザーマシンのセキュリティ確保については、「ユーザーの所有である場合を除き、実行中のプロセスをユーザーの目に触れさせてはならない」という、活発に議論されている教訓がある。このような制限は、Linux や BSD では簡単に有効にできるが、実際は、これで安心できるのだろうか。その答えは、「おそらく安心できる」であり、同時に「あまり意味はない」というところだ。

「おそらく安心できる」と思われる方は、プロセスの引き数を考えていただきたい。コマンドに一連の引き数を付けて実行すると、そのコマンドと引き数は「ps」実行時のリストに表示される。また、コマンドラインでパスワードも入力すれば、プロセスが実行中の間は「ps」を実行するユーザー全員にこれが見えてしまう。ユーザーがサーバー上で実行中のデーモンプロセスを見えるようにするのは攻撃目標を教えるようなものだ、という考えは多い。いずれにせよ、この情報はほかの方法を使えば簡単に入手できるので、「あまり意味はない」ということになる。

この議論が始まると、必ずだれかが「chroot jail」の話を持ち出してくる。「chroot」は「change root （root の変更）」の略で、まさしくその処理を行う。

「chroot /home/charlie /bin/bash」というコマンドを実行すると、chroot がシェルで/home/charlie/bin/bash を実行し、/home/charlie にユーザーを閉じこめる。「bash」シェルが有効な限り、ファイルシステムの新しい root は/home/charlie となる。これで、実際のファイルシステムへのアクセスは、この場所以外はまったくできなくなる。そして、利用可能なあらゆるコマンドと、それに必要なライブラリは、この chroot jail にコピーする必要がある。便利な環境を実現するのは一苦労なのだ。実際は、ユーザーごとに専用の Linux Xen や Solaris Zone インスタンスを与えた方が簡単だ。

最後に説明するのが制限付きシェルだ。最も人気の高い「rbash」は、制限付きの bash シェルだ。ユーザーのシェルを rbash に設定すると、間違いなく完全にセキュリティが消えてしまう。rbash は理論上、「./」（現在のディレクトリ）を含め、ユーザーがフルパスを指定して何かを実行することができなくする。これはつまり、自分で書いたスクリプトやダウンロードしたエクスプロイトコードをはじめ、ユーザーがコマンドを実行しにくくなることを意味する。

「$PATH」はグローバルでコントロールされているため、ユーザーはこれらの場所でしか何かを実行することができない。残念ながら、「/bin/」もこれらのパスのなかに置かなければならないため、ユーザーは新しいシェルを実行するだけであり、rbash は「exec bash」で見えなくなる。
これを緩和するには、ユーザーのパスに管理者が作成したディレクトリしか与えない、という方法もある。このディレクトリのなかでは、すべての正規コマンドに symlink を配置するだけだ。設定は chroot 同様に厄介だが、こちらの方がはるかに許容度が高い。

ユーザーがダウンロードしたプログラムを実行できなくする方法がいくつかあるのは確かだが、結局のところ、システムのマルチユーザー環境下におけるセキュリティは、インストールされたすべてのソフトウェアのセキュリティに依存することになる。そして、SELinux のようにエクスプロイトコードの被害を防ぐことが、最も実用的な手段となる。頻繁にアップデートされるシステムと組み合わせれば、rbash のような新たな制限も一般には必要でなくなる。

では、ここで学んだ本当の教訓は何だろう。セキュリティは不便だということだ。そして、もしそれが不便でないのなら、その方法はどこかが間違っているということだ。