0

ユーザーが特定のMLS感度レベルでログインできるかどうかを決定するロジックを理解しようとしています。最初は、pam_selinux.soが/ etc / selinux /.../ seusersファイルを読み取って、どのユーザーがどのseuserにバインドされているかを理解し、MLS範囲の上位コンポーネント以下の感度にユーザーを制限しているのではないかと思いました。

ただし、ソースコードを調べた後、ユーザーにセキュリティコンテキストをデフォルトのコンテキストから変更するかどうかを尋ねた後、pam_selinuxは、カーネルポリシーを呼び出して、新しいMLSラベルが適切かどうかを確認します。

次のコードは、Ubuntulibpam-modules1.1.1-4ubuntu2パッケージのmodules/pam_selinux/pam_selinux.cにあります。

static int mls_range_allowed(pam_handle_t *pamh, security_context_t src, security_context_t dst, int debug)
{
  struct av_decision avd;
  int retval;
  unsigned int bit = CONTEXT__CONTAINS;
  context_t src_context = context_new (src);
  context_t dst_context = context_new (dst);
  context_range_set(dst_context, context_range_get(src_context));
  if (debug)
    pam_syslog(pamh, LOG_NOTICE, "Checking if %s mls range valid for  %s", dst, context_str(dst_context));

  retval = security_compute_av(context_str(dst_context), dst, SECCLASS_CONTEXT, bit, &avd);
  context_free(src_context);
  context_free(dst_context);
  if (retval || ((bit & avd.allowed) != bit))
    return 0;

  return 1;
}

このチェックは、security_compute_av（）呼び出しで見られるように、カーネルポリシーで実際にチェックされているように見えます。これにより、SELinuxログインについての私の理解が頭に浮かびました。

だから、誰かが説明してもらえますか？

  • ユーザーが選択したログインセキュリティレベルの有効性はどのように決定されますか？

  • そのロジックは、ポリシー、pam_selinux、およびカーネルにどの程度正確に実装されていますか？

現在、私はタイプエンフォースメントマルチ、カテゴリセキュリティ、またはロールベースのアクセス制御にはあまり興味がないので、MLSの感度に影響を与えない場合、これらのコンポーネントがどのように検証されるかを説明する必要はありません。

4

1 に答える 1

2

「SELinuxが私の脳を半分に折りたたむ」という問題も共有していることを考えると、私は助けることができると思います。何よりもまず、随意アクセス制御と強制アクセス制御の違いを覚えておく必要があります。また、ユーザースペースは多くのことを定義しますが、カーネルはそれらを強制するようになることも覚えておく必要があります。

まず、ユーザースペースとカーネルスペースの問題の部分的なリストを次に示します。

  • ユーザースペースは有効なユーザーIDを定義し、カーネルはそのユーザーID（名前ではなく番号）が所有するプロセスを作成します
  • ユーザースペースは、ext3 / 4ファイルシステム上のファイルにアクセス許可と所有権を設定します。カーネルは、ファイルiノードと後続のすべての親ディレクトリiノードに基づいてそのファイルへのアクセスを強制します。
  • 2人のユーザーがで同じユーザーIDを共有する場合/etc/passwd、強制はテキストの識別子ではなく数値の識別子によって行われるため、カーネルは両方に同じ特権を付与します
  • ユーザースペースが別のホストへのネットワークソケットを要求すると、カーネルはその会話を同じシステム上の他のホストから分離します
  • SELinuxでは、ユーザースペースがを介してロール、ログイン、およびユーザーを定義しsemanage、カーネルがそれらを大きなAccess Vector Cache（AVC）にコンパイルして、ロールベースのアクセス制御と強制アクセス制御を適用できるようにします。
  • また、SELinuxでは、セキュリティ管理者はsemanage最小および最大のセキュリティコンテキストを定義するために使用できます。マルチレベルセキュリティ（MLS）構成を使用していて、ログイン中にユーザーがコンテキストを選択すると、カーネルはそれをAVCに対して測定して、許可されているかどうかを判断します。

これが理にかなっていると思われるのは、マルチレベルのセキュリティ構成にすることです。SELinuxでクラスを受講し、約2時間触れました。ほとんどの人はそこに行きたくないです。これまで。私はかなりMLS構成になっているので、あなたが追いかけていたコーディング決定の背後にある理由を理解していますが、MLSをいじくり回すことは、PAMがどのようにそしてなぜそのように機能するかを理解するためのかなり苦痛な方法であることに同意します。

随意アクセス制御（DAC）は、ユーザースペース、特にroot以外のユーザーが、制御するデータに誰がどのようにアクセスできるかを定義できる場所です。ファイルのパーミッションを考えてください。ユーザーがそれを制御するため、あるユーザーが別のユーザーが所有するプロセスやファイルを表示できるようにするために必要な労力はわずかです。通常、優れた管理者は、1人のユーザーがボックス全体を危険にさらす可能性があると想定し、すべてのユーザーが平等に信頼されるため、それほど気にしません。これはほとんど信頼できないかもしれませんが、それでもある程度の信頼はあります。

強制アクセス制御（MAC）は、ユーザースペースが信頼されない場所です。すべてのユーザーが平等に作成されるわけではありません。非MLSの観点から、同じハードウェア上にWebサーバーとデータベースサーバーがある場合を考えてみてください（スラッシュドット効果に耐えることはできません）。2つのプロセスが通信するのは、TCPを介した専用接続チャネルを介した場合のみです。そうでなければ、彼らは他が存在することさえ知らないはずです。2つの異なるコンテキストでそれらを操作し、カーネルが分離を強制します。プロセステーブルを見たり、ルートとしてハードドライブをさまよったりしても、コンテキストを変更しない限り、近づくことはできません。

MLSの構成では、感度とコンテキストのランダムな組み合わせを取得しようとした回数がわかりませんが、無効な組み合わせを選択した場合にのみ拒否されます。既存のポリシー（ Red Hat 5のポリシー）を調べて、それが何であるか、または許可されていないかを知る/etc/selinux/には、多くの調査が必要になるため、非常にイライラする可能性があります。/src/policy/policy

厳密な構成では、これらすべてがやり過ぎである理由がはっきりとわかります。そしてそれは、SELinuxが単純な状況ではやり過ぎだからです。部分的に利用できる他の機能もありますが、その中で最も重要なのは、管理者が設定したアクセス許可を適用するきめ細かいアクセス制御です。これが最もよく使用される領域の1つは、サービスデーモンを必要な基本的なアクセスだけに制限することです。/bin/ls新しいデーモンを設定するのは面倒ですが、問題のプロセスがデーモンやシェルなどの非デーモンコマンドを実行できない役割に割り当てられている可能性があるため、共有ライブラリのエクスプロイトなどの些細なエクスプロイトがそれ以上進まないようにします。 。このような状況では、エクスプロイトはあまり役に立ちません。

于 2011-04-11T03:28:32.770 に答える