前回の記事では、非常に高いレベルでの認証のためにPAMライブラリを呼び出すアプリケーションのフローについて説明しました。この記事では、ローカルの sudoの構成ファイルについて説明します。 コマンド。
sudoを使用する場合 、ユーザーを切り替えて何かをします。この特権の変更には、私たちが本人であり、与えられたアクションを実行することが許可されていることを確認する必要があります。 / etc / sudoers ファイルは誰が何を実行できるかを制御しますが、プロセスは認証チェックのためにPAMを呼び出します。これらの呼び出しの一部として、プロセスはそれ自体を識別し、次に libpam /etc/pam.dで一致する構成ファイルを探します ディレクトリ。
$ cat /etc/pam.d/sudo
#%PAM-1.0
#Type ReturnCode Modules Options
auth include system-auth
account include system-auth
password include system-auth
session optional pam_keyinit.so revoke
session required pam_limits.so
session include system-auth
他の多くの*.dディレクトリと同様に、パッケージ管理はこのディレクトリにファイルを追加または削除する場合があります。 sudo RPMは/etc/pam.d/sudoを追加します ファイル。
$ rpm -qf /etc/pam.d/sudo
sudo-1.9.0-0.1.b4.fc31.x86_64
アップストリームバージョンにはさまざまなエントリが含まれている可能性がありますが、このディストリビューション提供のパッケージには、いくつかの includeを含む構成ファイルが含まれています。 一般的な/etc/pam.d/system-authへのステートメント pamによって提供されるファイル パッケージ。
構成ファイルフィールド
このファイルの最初のフィールドは、タイプを識別します PAMへの呼び出しの。同じタイプの行はグループ化されます。認証、アカウント、パスワード、セッションの4つのタイプがあります。 man pamを見てください 各タイプの説明については。
2番目のフィールドはReturnCodeとして知られています 。このフィールドにより、PAMはモジュールテストの結果を処理する方法を知ることができます。戻りコードは、テストが必須かオプションかを示します。コードは、その行がオプションを使用したモジュールテストではなく、追加のチェックを含む別の構成ファイルの名前であることを示すためにも使用される場合があります。リターンコードの完全な説明は、 man pam.confにあります。 、および最も一般的なものについては、この記事の後半で説明します。
行の残りの部分には、モジュール名とそのモジュールのオプションが含まれています。モジュール名は、 / etc / lib64 / securityで使用可能なモジュールと一致する必要があります ディレクトリ。オプションは、行われた呼び出しのタイプによって異なる場合があります。一部のモジュールは、特定のタイプの呼び出しに対してのみテストを実行します。各モジュールのマニュアルページを使用して、例を確認し、使用可能な使用法とオプションについて学習してください。
あるタイプの呼び出し内のエントリの順序が重要です。これは主にリターンコードの処理方法が原因ですが、モジュールアクションが原因の場合もあります。 libpamの場合 「done」または「die」メッセージを受信すると、全体的な結果が呼び出しプロセスに報告されます。
sudoの構成 いくつかのインクルードがあります 行。これらの行はlibpamに通知します 指定された構成ファイルから指定されたタイプのすべての行を含める。 サブスタックもあります オプション。これは、特定の構成ファイルの行を含める方法と似ていますが、「完了」または「ダイ」の場合、サブスタックに報告します。 libpamを呼び出す元のプロセスの代わりに命令 。古いバージョンのPAMには、他の構成ファイルが含まれる方法に他のバリエーションがありました。たとえば、私が20年近く前にPAMの調査を開始したとき、引数として構成ファイルを使用して呼び出される特定のモジュールがありました。キーワード「include」がReturnCodeに対して無効でした フィールド。
中央構成ファイルの戻りコード
/etc/pam.d/sudo 前に示したファイルはかなり短いです。 4つの通話タイプのうち3つには、インクルードしかありません 別のファイルの。 /etc/pam.d/system-auth ファイルは構成ファイルのより一般的なものであり、呼び出しのタイプごとに多くのチェックが行われます。
$ cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_sss.so forward_pass
auth required pam_deny.so
...omitted... 必須 キーワードはおそらく最も一般的です。これは、モジュールが全体的なパスをアプリケーションに返すためにチェックに合格する必要があることを示しています。ただし、障害が発生した場合でも、そのタイプの次の行はチェックされます。これは、認証失敗の理由を共有しないという長年の慣習です。 20年前のシステムでは、認証が失敗するまでにかかった時間によって、認証がどのように失敗したかを推測できた可能性があります。
必要条件 キーワードは必須に似ています チェックに合格する必要がありますが、失敗した場合は「ダイ」メッセージが返されます。 必要条件 libpam 次の行はチェックされないことを知っており、呼び出しプロセスに全体的な結果（この場合は失敗）を通知します。
十分 キーワードはrequisiteのほぼ反対です 。成功すると、「完了」メッセージが返され、 libpam 先に進み、全体的な結果を呼び出し元のアプリケーションに送り返します。このモジュールの他の結果は無視され、チェックが続行されます。
十分 キーワードは、基準を検証する方法が複数ある可能性がある場合に一般的です。たとえば、パスワードを確認する場合、ユーザーはローカルの / etc / passwdで定義されている可能性があります。 および/etc / shadow ファイル、または sssdでアクセスされる中央システムでのみ定義される場合があります 。 pam_unix モジュールはローカルファイルをチェックします。成功した場合は、一元化されたサービスを続行して確認する必要はありません。ただし、ユーザーがローカルで定義されていない場合は、失敗を記録したくないので、結果を無視して pam_sssを試してください。 モジュール。 十分なので キーワードが本当に失敗することはありません。必要なpam_denyを追加するのが一般的です。 一連の十分の後の行 行。 pam_deny モジュールは常に/bin / falseのように失敗します 実行可能ファイル。
オプション キーワードは十分に似ています 失敗を無視するという点で。ただし、成功すると、必須のように機能します。 「ok」値を設定し、追加のチェックを続行してキーワードを設定します。
両方とも必要なので および十分 モジュールのスタックからの出口点になる可能性がある場合、構成ファイル内の順序が重要です。これらのキーワードの後の行は、実行される場合と実行されない場合があります。
複雑なリターンコード
単純なキーワード構文に加えて、複雑な戻りコードは角括弧内のキーと値のペアで定義されます。 /etc/pam.d/system-auth ファイルには、より複雑な構文のセッションセクションにサンプルがあります。
$ cat /etc/pam.d/system-auth
...omitted...
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
各キーワードに一致する複雑な構文は、 pam.confにあります。 マニュアルページ。 - 上記のように、manページでも定義されています。モジュールがシステムにインストールされていない場合、ログをスキップできることを示しています。
次は何ですか？
これで、 libpamを使用して呼び出しと終了が発生したときにウォークスルーできるようになりました。 、次のステップは、各モジュールのユースケースをよりよく理解することです。ほとんどのモジュールには、使用法を説明し、 pam.dに表示される行の例を示すマニュアルページがあります。 構成ファイル。一部のモジュールは、 / etc / securityの補足ファイルも参照します。 ディレクトリ。これらのファイルにはコメントが付けられており、多くの場合、独自のマニュアルページがあります。 pam_pwquality およびpam_limits モジュールは、始めるための良い例です。
まとめ
次の記事では、 authconfigを使用して行われた変更のいくつかについて説明します。 効用。自分でファイルの編集に取り掛かりたい場合で、Red Hat Learningサブスクリプションをお持ちの場合は、Red Hat Security：Linux in Physical、Virtual、and Cloud（RH415）コースのPAMに関する章をご覧ください。
[無料のオンラインコース：Red HatEnterpriseLinuxの技術概要。 ]