web-dev-qa-db-ja.com

シェルプログラムの実行を許可するユーザーのシェルを制限する方法

Ls、rm、およびシステムに害を及ぼす可能性のあるその他のシステムコマンドなどのコマンドをユーザーが使用しないようにすることは可能ですか。しかし、ユーザーはシェルプログラムを実行できるはずです。

linuxscriptingshell
9
Hulk

あなたの質問は：

ユーザーを信用していません。馬鹿な人はインターネットで何かを見て、それが何をしているのか理解せずにそれを試します。悪意のある人は、他の人のファイルを覗き見してそれらのアイデアを盗むのが好きです。そして、怠惰な私に怠惰なものから始めさせないでください。

システムからユーザーをユーザーから保護するにはどうすればよいですか？

まず、unixには非常に包括的なファイルシステム許可システムがあります。 これはUNIXファイルシステムのアクセス許可に関する適切なチュートリアルのようです 。この要点は、ユーザーがディレクトリに移動してそのディレクトリからプログラムを実行できるが、そのディレクトリの内容を表示できないようにディレクトリを設定できることです。たとえば、/ homeでこれを行うと、ユーザーが/ homeでlsを実行すると、権限拒否エラーが発生します。

ユーザーが本当に怖くて、制限された環境の supermax タイプに固定したい場合は、freebsdのjailやsolarisのゾーンのようなものを使用します-各ユーザーは独自のテーラーメード環境を取得します。追加されたポイントについては、ZFSを使用して、ログイン時に環境のスナップショットを取得できるので、ファイルが削除された場合、スナップショットからそれらをプルすることができます。

11
chris

あなたが求めていることを完全に行うには、次の3つのことが必要です。

  1. 必要なコマンドが不足しているカスタムシェル。これを取得するのは難しいことですが、本当にユーザーに一部のシェルプリミティブへのアクセスを許可したくない場合は、これがそれらを削除する唯一の方法です。
  2. ファイルの権限を正しく設定。ユーザーにシステムを損傷させたくないですか？適切なツールがあっても、システムに損傷を与えないようにアクセス許可を設定します。これらの3つのステップのうち、これが最も簡単なステップです。
  3. AppArmorのような必須のアクセス制御技術を使用。 AppArmorやSELinuxなどのMACは、アクセス許可をカーネルに埋め込みます。これらは、ユーザーがどこかにそれらを見つけた場合でも適切なツールを実行できないようにします（ファイルのアクセス許可のように、制限されたボックスの外では使用できません）。

ベルト、サスペンダー、およびメジャーのための主砲。間違えにくいです。

特定の実行可能ファイルのMACはすべての子によって継承されるため、AppArmorは興味深いものです。ユーザーのログインを_/bin/bash-bob_に設定し、その特定のバイナリ権利のAppArmorプロファイルを設定します。ユーザーがそのアクセス許可の刑務所から抜け出す唯一の方法は、カーネルの悪用です。なんらかの遅延インストールスクリプトが何らかの愚かな理由で_/var/opt/vendor/tmp_グローバル書き込み可能のままにした場合、_/bin/bash-bob_をシェルとして使用しているユーザーはそこに書き込むことができません。ホームディレクトリと_/tmp_への書き込みのみを許可するようにbash-bobプロファイルを設定します。このような権限の誤りは利用できません。彼らがどうにかしてrootパスワードを見つけたとしても、suとそれが生成するsuプロセスが_/bin/bash-bob_の子であるため、bashが起動した後でも、_/bin/bash-bob_のAppArmorプロファイルは引き続き適用されます。

難しいのは、そのAppArmorプロファイルを構築することです。

  1. / bin/bash-bobのAppArmorプロファイルを作成し、監査モードに設定します
  2. ボブのログインシェルを/ bin/bash-bobに設定します
  3. Bobとしてログインします。ボブにできることをすべて実行します。
  4. 監査ログを使用してAppArmorプロファイルを作成します（SUSEにはこのためのツールがあり、他のLinuxディストリビューションについては不明です）。これは非常に退屈な作業ですが、このレベルのセキュリティが必要な場合に発生する必要があります。
    1. あなたは次のようなことをするでしょう：
      • ほとんどのシステムライブラリへの読み取りアクセスの承認
      • 選択されたいくつかの許可されたシステムコマンドに対する読み取りおよび実行権限の承認
      • 一時スペースへの書き込みアクセスの承認
      • 必要に応じて、ソケット作成の承認
  5. 実施するポリシーを設定します。
  6. Bobとしてログインし、操作を行います。
  7. 調整を行います。

私の意見では、手順2と3だけが必要です。両方を組み合わせると、両方の手順でセットアップした慎重に構築されたボックスの外側で有害なことを実行する能力が両方とも妨げられるためです。

9
sysadmin1138

ユーザーのシェルを設定する に、特定のシェルスクリプトのみを実行できるように記述したプログラムを指定できます。

もちろん、これはプログラムとシェルスクリプトと同じくらい安全です。実際には、この種の制限付きシェルは通常、スマートな攻撃者に対して安全ではありません。

4
Jason Orendorff

コマンドを制限したり、ファイルのアクセス許可を制限したりしないでください。 syscallへの人々のアクセスを実質的に制限することはできないので、誰かが行う必要があるのは、実行させたくない「危険な」コマンドのコピーを自分で提供することだけであり、あなたは詰まっています。

3
womble

ユーザーが特定のスクリプト/バイナリのみを実行できるようにしたい場合は、 制限付きシェル を使用できます。これは（ウィキペディアの記事で言及されているように）完全には安全ではありませんが、実行を許可されているアプリケーションが新しいシェルを実行できないことを保証できる場合は、優れた代替手段です。

ユーザー制限付きシェルを設定するには、/bin/rbash（または同様に、バイナリがr *** name *という名前のときにほとんどのシェルが制限付きモードに入ります）をユーザーシェルとして設定します。次に、**。bashrc（または同等のもの）を編集し、$PATHを、許可されたすべてのバイナリ/スクリプトが格納されているディレクトリに設定します。

2
Mikael S

[lshell] [1]（制限付きシェル）を試してみてください。

lshellはPythonでコード化されたシェルであり、ユーザーの環境を制限されたコマンドセットに制限したり、SSH経由のコマンド（SCP、SFTP、rsyncなど）を有効/無効にしたり、ユーザーのコマンドをログに記録したり、タイミング制限を実装したりできます。もっと。

[1]： http://lshell.ghantoos.org/Overview lshell

1
Elifarley

私が通常この種の制限を実装する方法では、いくつかの条件が満たされている必要があります。そうでない場合、制限は簡単に回避できます。

  • ユーザーはwheelグループに属していません。suの使用が許可されている唯一のグループです（PAMによって強制されます）。

  • ユーザーには適切に保護されたrbashが与えられ、読み取り専用PATHはプライベート~/binを指します。この~/bin/ディレクトリにはリンクが含まれます単純なユーティリティへ：

    $ ll ~/bin
total 0
lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 clear -> /usr/bin/clear*
lrwxrwxrwx. 1 root dawud  7 Sep 17 08:58 df -> /bin/df*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 egrep -> /bin/egrep*
lrwxrwxrwx. 1 root dawud  8 Sep 17 08:58 env -> /bin/env*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 fgrep -> /bin/fgrep*
lrwxrwxrwx. 1 root dawud  9 Sep 17 08:58 grep -> /bin/grep*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 rview -> /bin/rview*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 rvim -> /usr/bin/rvim*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 Sudo -> /usr/bin/Sudo*
lrwxrwxrwx. 1 root dawud 17 Sep 17 08:58 sudoedit -> /usr/bin/sudoedit*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 tail -> /usr/bin/tail*
lrwxrwxrwx. 1 root dawud 11 Sep 17 08:58 wc -> /usr/bin/wc*

  • ユーザーには、制限された読み取り専用環境が与えられます（LESSSECURE、TMOUT、HISTFILE変数などを考えてください）。

  • ユーザーはSELinuxユーザーstaff_uにマップされ、Sudoを介して必要に応じて他のユーザーとしてコマンドを実行する権限が与えられます。

  • ユーザーの/home、/tmp、および場合によっては/var/tmpは、/etc/security/namespace.confを介して多重インスタンス化されます。

    /tmp       /tmp/.inst/tmp.inst-$USER-     tmpdir:create   root
/var/tmp   /tmp/.inst/var-tmp.inst-$USER- tmpdir:create   root
$HOME      $HOME/$USER.inst/              tmpdir:create   root

    また、/etc/security/namespace.initは、すべての骨格ファイルをユーザーに対して読み取り専用にし、rootが所有するようにします。

このようにして、$USERが自分の代わりにコマンドを実行できるかどうかを選択できます（上記で説明したように、~/binを介してプロビジョニングされたプライベート/etc/skelディレクトリ内のリンクを介して）。他のユーザーの（Sudo経由）またはまったくなし。

1
dawud

はい、可能ですが、実際には多くの作業と計画が必要になります。スクリプトを作成して特権使用として実行し、問題のユーザーからすべての特権を削除できます。または、ユーザーのシェルを、ユーザーが明示的に許可したものだけを実行できるようにする独自の設定に設定することもできます。

ただし、Linuxの標準の権限では、通常のユーザーが「システムに害を及ぼす」ことはほとんど不可能です。どんな害を防ごうとしていますか？ユーザーがホームディレクトリの外でソフトウェアをインストールしたりプログラムを実行したりできないようにするのは簡単です。chrootを使用してシステムをさらにロックダウンすることができます。

1
Bryan Oakley

はい、これらのコマンドの権限を変更するだけです。

要件に応じて動作するシェルコマンドを作成することで、より良い戦いの可能性があるかもしれません。

Linuxの通常のユーザーにデフォルトの権限として適切でないものは何ですか？

0
jldupont