カスタムPAMモジュールとセキュリティに関する考慮事項

開発中のアプリケーションの一部となる独自のPAMモジュールを作成していますが、どこに配置するか正確にはわかりません。私のモジュールは基本的にLDAPと同様にネットワークレベルの認証を行います（もちろん他のモジョを使用します）。

私の/etc/pam.d/ディレクトリには多くの設定ファイルがあり、ほとんどのサービスが何をしているかを知っています（atd、polkit、pppのようなカップルを除く）。PAMスタックでの認証は次のようになると思います：

1. サービス名に基づいてスタックを実行します（構成ファイルが存在する場合）
2. 認証されていない場合は、common- *にフォールバックします。*はモジュールタイプ（auth、accountなど）です。
3. 成功を返すか、呼び出しアプリケーションに失敗します（もちろん他のデータも）

この仮定は正しいですか？ すべてのプラットフォームに共通認証、共通アカウント、共通パスワード、および共通セッションがありますか？

もしそうなら、私はそれをsufficientモジュールとしてcommon- *の一番上に置くことを考えていたので、失敗したときに通常のPAMスタックは影響を受けません。ソフトウェアのインストール時にプログラムでこれを実行できるため、これは特に有利です。

潜在的なセキュリティの脆弱性を見逃していますか？

カスタムPAMモジュールを統合する場所や、モジュールを配置する場所を取り巻くセキュリティの問題に関する、適切なドキュメントが見つかりませんでした。

認証手順のためにLinux-PAMを呼び出す場合、実行されるスタックは常に1つだけです。

スタック定義はこれらの場所で検索されます。最初に成功した試行により、どのファイルが読み取られるかが決まります。

1. /etc/pam.dアプリケーションの「サービス名」に基づいて名前が付けられたファイル（例：sshdまたはgdm）、または

2. ファイル/etc/pam.d/otherなしサービス固有のファイルが存在しない場合、または

3. /etc/pam.confディレクトリ/etc/pam.dが存在しない場合のファイル。

詳細については、関数pam_startのドキュメントを参照してください。

common- *ファイルは、多くのLinuxディストリビューションが従う規則ですが、PAMソフトウェア自体では必須ではありません。それらは通常、@include ステートメントによって他のPAMファイルに含まれます。たとえば、/etc/pam.d/otherDebian のファイルには次の内容があります。

# We fall back to the system default in /etc/pam.d/common-*
@include common-auth
@include common-account
@include common-password
@include common-session

同じ@includeステートメントがサービス固有のファイルでも使用される可能性があり、実際、Debianのデフォルト構成にあります。これは構成の問題であることに注意してください/etc/pam.d。sysadminは、common- *ファイルをまったく含まないようにファイルを自由に変更できます。

したがって、PAMモジュールがアプリケーションに固有の場合は、アプリケーション固有のサービスファイルを作成し、そこからモジュールを呼び出します。モジュールを他のサービスのPAMファイルまたはフォールバックファイルに自動的に追加しないでください。追加するothersと、システムにインストールされている他のアプリケーションが破損する可能性があります。PAMソフトウェアスタックの管理は、アプリケーション開発者ではなく、システム管理者のタスクです。