☰

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

tag-icon • tag-icon security authentication pam
カスタムPAMモジュールとセキュリティに関する考慮事項

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

私のディレクトリには多くの設定ファイルがあり、ほとんど/etc/pam.d/のサービスがどの用途に使用されているかを知っています（atd、polkit、pppなどの一部のサービスを除く）。私はPAMスタックの認証が次のとおりです。

  1. サービス名に基づいてスタックを実行する（設定ファイルがある場合）
  2. 認証されていない場合は、common-*を使用してください。ここで、*はモジュールタイプ（認証、アカウントなど）です。
  3. 呼び出しアプリケーションに成功または失敗を返します（もちろん、他のデータと共に）。

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

sufficientその場合は、障害が発生したときに通常のPAMスタックが影響を受けないように、common-*の上にモジュールとして配置することを検討しています。ソフトウェアのインストール時にプログラムでこれを行うことができるため、これは特に有利です。

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

カスタムPAMモジュールを統合する場所やモジュールの配置場所に関連するセキュリティ上の問題に関する良いドキュメントが見つかりません。

ベストアンサー1

一部の認証プロセスに対して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ソフトウェア自体では必要ありません。通常、他のPAMファイルにステートメントとして含まれます@include 。たとえば、/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.dcommon-*ファイルがまったく含まれないようにファイルを自由に変更できます。

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

おすすめ記事