ホームページ >システムチュートリアル >Linux >Linux 権限制御の基本原則

Linux 権限制御の基本原則

王林
王林転載
2023-12-31 15:59:501269ブラウズ

この記事では主に、Linux システムにおけるアクセス許可制御の基本原則を紹介します。 Linux 権限制御の基本原則

セキュリティモデル

Linux システムでは、すべての操作は基本的にファイルにアクセスするプロセスの操作です。ファイルにアクセスするには、まず対応するアクセス許可を取得する必要があります。アクセス許可は、Linux システムのセキュリティ モデルを通じて取得されます。

Linux システムのセキュリティ モデルについては、次の 2 つの点を知っておく必要があります。

  1. Linux システムの元のセキュリティ モデルは DAC と呼ばれ、その正式名は Discretionary Access Control、つまり任意のアクセス制御と訳されます。
  2. その後、MAC と呼ばれる新しいセキュリティ モデルが追加および設計されました。その正式名称は、Mandatory Access Control で、強制アクセス制御と訳されます。

MAC と DAC は相互に排他的ではないことに注意してください。DAC は最も基本的なセキュリティ モデルであり、通常、Linux に必要な最も一般的に使用されるアクセス制御メカニズムです。MAC は、DAC 上に構築された拡張セキュリティ メカニズムです。 はオプションのモジュールです。 。 Linux システムは通常、アクセスする前に最初に DAC チェックを実行します。これが失敗した場合、操作は直接失敗します。DAC チェックに合格し、システムが MAC モジュールをサポートしている場合は、次に MAC アクセス許可チェックを実行します。

この 2 つを区別するために、MAC をサポートする Linux システムを SELinux と呼びます。これは、Linux 用のセキュリティが強化されたシステムであることを意味します。

ここでは、Linux システムにおける DAC セキュリティ モデルについて説明します。

DACセキュリティモデル

DAC の中心的な内容は次のとおりです。 Linux では、理論上、プロセスはそれを実行するユーザーと同じ権限を持ちます。関係するものはすべてこのコアを中心に展開されます。

ユーザーおよびグループ ID 情報の管理

ユーザー、グループ、パスワード情報

/etc/passwd および /etc/group を介してユーザーとグループの情報を保存し、/etc/shadow を介してパスワードとその変更情報を 1 行に 1 つのレコードで保存します。

ユーザーとグループは、それぞれ UID と GID で表されます。ユーザーは同時に複数のグループに属することができます。デフォルトでは、各ユーザーは同じ UID 値と同じ名前の GID に属する必要があります。

/etc/passwd の場合、各レコード フィールドはユーザー名: パスワード (暗号化され、/etc/shadow に保存されます): UID: GID (デフォルトの UID): 説明コメント: ホーム ディレクトリ: ログイン シェル (最初の実行プログラム)

/etc/group の場合、各レコードのフィールドは、グループ名: パスワード (通常、グループ パスワードはありません): GID: グループ メンバー ユーザー リスト (カンマ区切りのユーザー UID リスト)

/etc/shadow の場合、各レコードのフィールドは次のとおりです: ログイン名: 暗号化されたパスワード: 最終変更時刻: 最小時間間隔: 最大時間間隔: 警告時間: 非アクティブ時間:

######例######

次に、ユーザーおよびグループ情報の例を示します。 /etc/shadow 内のパスワード情報は暗号化されて保存されますが、例は示されていません。

ファイル権限制御情報Linux 権限制御の基本原則

######ファイルの種類###### Linux のファイル タイプは次のとおりです: テキスト ファイルやバイナリ ファイルなどの通常のファイルをタッチで作成できます;

ネットワーク通信に使用されるソケット ファイルは、通常、実行中にアプリケーションによって間接的に作成されます。 パイプ ファイルは名前なしパイプではなく名前付きパイプであり、mkfifo を使用して作成できます;

キャラクター ファイルとブロック ファイルはデバイス ファイルであり、mknod で作成できます;

    リンク ファイルはハード リンク ファイルではなくソフト リンク ファイルであり、ln を使用して作成できます。
  • アクセス制御グループ
  • 制御のために 3 つのグループに分けられます:
  • user にはファイル所有者に設定された権限が含まれます

グループには、ファイル グループに設定された権限が含まれます others には、他の人に設定された権限が含まれます

    設定可能な権限
  • 一般的な (すべてではない) 権限の値を以下に示します。
  • r は読み取り許可を意味します。

w は書き込み権限があることを意味します。 x は通常、実行可能ファイル/ディレクトリ用であり、実行/検索権限があることを示します。

s は通常、実行可能ファイル/ディレクトリ用であり、ファイル所有者に権限を付与する権限があることを示します。この権限を設定できるのはユーザーおよびグループ グループだけです。

    t 通常、ディレクトリの場合、スティッキー ビットを設定した後、アクセス許可を持つユーザーは自分のファイルの書き込みと削除のみが可能で、それ以外の場合はディレクトリ内のすべてのファイルの書き込みと削除が可能です。また、古いシステムでは、速度を向上させるために、実行可能ファイルの実行後にテキストがスワップ領域にコピーされます。
  • ######例######
  • ls -l を使用してファイルの種類と権限を確認し、chmod を使用して権限を変更できます。
  • ###例えば、###
  • 出力の最初の文字は、通常ファイル (-)、ディレクトリ ファイル (d)、ソケット ファイル (s)、パイプ ファイル (p)、キャラクタ ファイル (c)、ブロック ファイルのファイル タイプを示します。 (b)、リンクファイル(l); 2文字目から始まる-rwxr-xr-xの部分はファイルの許可ビットを表し、合計9ビットになります。

    ファイル /usr/bin/qemu-i386 の場合、この権限制御の意味は次のとおりです:

    1. ビット 2 ~ 4 の rwx は、ファイルの所有者が r、w、または x のアクセス許可でファイルにアクセスできることを示します。
    2. ビット 5 ~ 7 の r-x は、r または x 権限を持つファイルと同じグループ内のユーザーがファイルにアクセスできることを示します。
    3. ビット 8 ~ 10 の r-x は、r または x 権限を持つ他の不明なユーザーがファイルにアクセスできることを示します。
    test/、test2/、test3/ に設定された権限:

    各権限制御グループの
      r,w,x 権限は 1 つの 8 進数で表されます。たとえば、755 は rwxr-xr-x を意味します。
    1. x 位置の代わりに
    2. s,t 権限が表示されます。s,t 権限を設定するには、r、w、x の制御に使用される対応する 8 進数の権限制御グループの前に数字を追加する必要があります。s 権限は、 owner グループ コントロールに属し、他のコントロールに使用されます。
    3. 所有者 s を設定するには 4 を追加し、グループ s を設定するには 2 を追加し、他のユーザーの許可 t を設定するには 1 を追加します。たとえば、test/ に t を設定する場合は、1775 を使用します。これは、rwxrwxr- を意味します。 t.
    プロセス権限制御情報

    プロセス権限

    プロセスの場合、次の属性はファイル アクセス許可に関連します:

      実効ユーザー ID: プロセス アクセス ファイルのアクセス許可に関連する UID (euid と略されます)。
    • 有効なグループ ID: プロセス アクセス ファイルのアクセス許可に関連する GID (egid と省略されます)。
    • 実ユーザー ID: システムにログインするときにプロセスを作成したユーザーの UID (ruid と省略)。
    • real group id: システムにログインするときにプロセスを作成したユーザーの GID (rgid と省略されます)。
    • 保存されたセットのユーザー ID: euid からコピーされました。
    • 保存されたセット グループ ID: egid からコピーされました。
    • ######例######
    ps と top を使用して、euid と ruid でプロセスを選択して表示できます。または、top を使用してプロセスの euid と ruid

    を表示します。 トップから表示する例:

    まず「top」と入力すると、次のような内容が表示されます

    ここでは、操作を容易にするために -d オプションを使用して top の更新頻度を延長しています。ここでわかるように、USER フィールドのみが、対応するプロセスの実効ユーザー ID を表します。

    読み取りユーザーIDの表示オプションを開きます:

    Linux 権限制御の基本原則a. top コマンドの実行中に「f」と入力すると、次のような行が表示されます。

    b. c と入力して、実ユーザー名の表示スイッチをオンにします。

    c. 最後に、Return キーを押して先頭に戻ると、実際のユーザー ID オプションが表示されます。この時点で「o」を入力して列の順序を調整します。最後に、次のように「実効ユーザー ID」と「実際のユーザー ID」を含む出力が表示されます。

    プロセス アクセス ファイルのアクセス許可制御ポリシー

    ######ルール######

    プロセスアクセスファイルの大まかな権限制御戦略

    ファイルにアクセスするプロセスにとって最も重要なのは euid であるため、そのアクセス許可属性はすべて euid を中心としています。

    プロセスの euid は通常、その ruid 値にデフォルト設定されます。 実行可能ファイルの実行許可ビットが s の場合、プロセスがそのファイルに対して exec を呼び出した後、その euid は実行可能ファイルのユーザー ID に設定されます。 プロセスの保存セット ユーザー ID は euid.

    からコピーされます。 プロセスのeuidがファイルのユーザーIDと一致する場合、プロセスにはファイルのユーザー許可ビットによって設定された許可のみが与えられます

    グループ権限 egid の制御ルールも同様です。

    exec 実行ファイルを使用して権限属性を変更する

      exec を通じて実行可能ファイルを呼び出す場合:
    • プロセス ruid 値は常に変更されません;
    • 保存されたセットユーザー ID は常に euid からのものです ;
    • euid 値は、ファイルの set-user-ID ビットが設定されているかどうかによって異なります。
    • ###次のように:###
    • setuid(uid) システムコールによる権限属性の変更

    setuid(uid) を通じて権限属性を変更する場合:

    スーパーユーザーは、ruid、euid、保存されたセットユーザー ID を正常に変更できます;
    • 特権のないユーザーは、uid が ruid と等しい場合にのみ euid を変更でき、それ以外の場合は変更できません。
    • ######例######
    • さらに特殊な例をいくつか見てみましょう:
    ユーザーIDの設定

    前述したように、この出力の意味は、/usr/bin/sudo ファイルの場合、
      • ビット 1 ~ 3 の rw は、ファイルの所有者が r または w または s の権限でファイルにアクセスできることを示します。
      • ビット 4 ~ 6 の r-x は、r または x 権限を持つファイルと同じグループ内のユーザーがファイルにアクセスできることを示します。
      • ビット 7 ~ 9 の r-x は、r または x 権限を持つ他の不明なユーザーがファイルにアクセスできることを示します。
      この設定の後、所有者は読み取り、書き込み、および実行のアクセス許可を持ちますが、これは変わりません。しかし、root グループに属さない通常のユーザー プロセスの場合は、まったく異なります。

      通常のユーザー プロセスが sudo コマンドを実行すると、他のプロセスの x を通じて実行権限を取得し、ユーザーの s を使用して sudo 実行可能ファイルの所有者 (ルート) の権限、つまりスーパー権限を一時的に取得します。 。

      これは、一般ユーザーが sudo コマンドを使用して管理者権限で多くのコマンドを実行できる理由でもあります。

      スティックビットが設定されました

      Linux 権限制御の基本原則

      この設定後は、誰もが /tmp ディレクトリに対する読み取り、書き込み、および実行のアクセス許可を持ちます。これは変わりません。ただし、スティッキービット t はその他の部分に設定されており、その機能はまったく異なります。

      ディレクトリにスティッキー ビットが設定されていない場合、ディレクトリへの書き込み権限を持つ人は、対応するファイルの所有者ではなく、読み取りまたは書き込み権限を持っていない場合でも、そのディレクトリ内のファイルおよびサブディレクトリを削除できます。スティッキー ビットが設定された後、ユーザーは自分に属するファイルとサブディレクトリのみを書き込みまたは削除できます。

      これが、誰でも /tmp ディレクトリにファイルやディレクトリを書き込むことができますが、書き込んだり削除したりできるのは自分が所有するファイルやディレクトリのみである理由です。

      set-user-id と保存された set-user-id の使用を説明する man プログラムのアプリケーション フラグメントを提供します。

      man プログラムを使用すると、オンライン ヘルプ マニュアルを表示できます。man プログラムをインストールすると、指定したユーザーまたはグループの set-user-ID または set-group-ID を指定できます。

      man プログラムは、特定の場所にあるファイルを読み取りまたは上書きできます。ファイルは通常、設定ファイル (通常は /etc/man.config または /etc/manpath.config) またはコマンド ライン オプションによって設定されます。

      man プログラムは、表示された man ページを含むファイルを処理するために他のコマンドを実行する場合があります。

      処理エラーを防ぐために、man は、man コマンドを実行するユーザーの権限と man プログラムの所有者の権限という 2 つの権限を切り替えます。

      把握する必要があるメインスレッド: man のみが実行される場合、プロセス権限は man ユーザーの権限になります。man を介して子プロセスが実行される場合 (!bash を介したシェルコマンドなど)、ユーザー現在のユーザーに切り替えます。実行後、ユーザーは現在のユーザーに切り替わります。また、元のユーザーに戻ります。

      プロセスは次のとおりです:

      man プログラム ファイルがユーザー man によって所有されており、set-user-ID ビットが設定されていると仮定すると、これを実行すると、次の状況になります。 – 実際のユーザー ID = ユーザー UID
    1. – 実効ユーザー ID = 男性ユーザー UID
      – 保存されたセットユーザー ID = 男性ユーザー UID

      man プログラムは、必要な設定ファイルと man ページにアクセスします。これらのファイルは man ユーザーによって所有されていますが、実効ユーザー ID は man であるため、ファイルへのアクセスは許可されています。
    2. 人間がコマンドを実行すると、setuid(getuid())) が呼び出されます (getuid() は実際のユーザー ID を返します)。 私たちはスーパーユーザー プロセスではないため、この変更では実効ユーザー ID のみが変更されます。次のような状況になります:
    3. man プロセスが実行されると、有効なユーザー ID として UID が使用されるため、独自の権限を持つファイルのみにアクセスできることになります。つまり、私たちの代わりにあらゆるフィルターを安全に実行できます。
    4. – 実際のユーザー ID = ユーザー UID (変更されません)
      – 実効ユーザー ID = 私たちのユーザー UID
      – 保存された set-user-ID = 男性のユーザー UID (変更されません)

      フィルターが完了したら、setuid(euid)を呼び出します。
      ここで、euid は man ユーザーの UID です (この ID は、geteuid を呼び出す man によって保存されます)。setuid パラメーターが保存された set-user-ID と等しいため、この呼び出しは問題ありません。 (これが、保存された set-user-ID が必要な理由です。) この時点では、次の状況になります:
    5. – 実際のユーザー ID = ユーザー UID (変更されません)
    6. – 実効ユーザー ID = 男性の UID
      – 保存された set-user-ID = 男性のユーザー UID (変更されません)

      実効ユーザー ID は man なので、man プログラムは独自のファイルを操作できるようになります。
      このように保存された set-user-ID を使用すると、プロセスの開始時と終了時にプログラム ファイルの set-user-ID を介して追加のアクセス許可を使用できます。しかし、この期間中、私たちは独自の権限の下で活動していました。最後に保存された set-user-ID に戻せない場合、実行中に追加のアクセス許可が保持される可能性があります。

    7. 人間がシェルを開始すると何が起こるかを見てみましょう:
    • ここでのシェルは、人間が fork と exec を使用して起動します。
    • 現時点では、実際のユーザー ID と実効ユーザー ID は両方とも通常のユーザー UID (ステップ 3 を参照) であるため、シェルにはその他の追加の権限がありません。
    • シェルの保存された set-user-ID は exec によって実効ユーザー ID からコピーされるため、開始されたシェルは man の保存された set-user-ID(man) にアクセスできません。
    • exec を実行する子プロセス (シェル) では、すべてのユーザー ID は通常のユーザー ID です。
    実際には、setuid 関数の使用方法を説明する方法は、プログラムがユーザー ID を root に設定する可能性があるため、特に正しいわけではありません。この時点で、setuid は 3 つの uid をすべて設定した ID に変更しますが、実効ユーザー ID のみを設定する必要があります。

以上がLinux 権限制御の基本原則の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事はlinuxprobe.comで複製されています。侵害がある場合は、admin@php.cn までご連絡ください。