PAM

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page PAM and the translation is 87% complete.

PAM 、またはプラグイン可能な認証モジュール (Pluggable Authentication Modules) は、認証のためのモジュール化されたアプローチです。PAM は、(サードパーティ製の) サービスが自身のサービスのために、PAM が有効化されたシステム上で利用可能な認証モジュールを提供できるようにします。認証のために PAM を使用するサービスは、再ビルドの必要なく、すぐにこれらのモジュールを使い始めることができます。

はじめに

Linux サーバ上での認証管理 (アクセス管理の一部) は PAM (Pluggable Authentication Modules) によって取り扱うことができます。PAM を使用すると、サービスは認証サービスを自身で提供する必要がなくなります。代わりに、システム上で利用可能な PAM モジュールに依存するのです。ほとんどの場合認証はサービスを問わず同様に扱われますが、もしそうしたいなら、それぞれのサービスは異なる PAM 設定を使用することができます。PAM モジュールを呼び出すことで、サービスを簡単に 2 要素認証に対応させたり、すぐに中央集権型認証リポジトリを使用させたり、その他さまざまなことが行えます。

PAM は以下のサービスに関して、柔軟なモジュール化されたアーキテクチャを提供します:

  • 認証管理 - ユーザアカウントを認証しようとしているユーザが、実際にそのユーザであるか検証します。
  • アカウント管理 - ユーザのパスワードの期限が切れていないか、またはユーザから特定のサービスへのアクセスが許可されているか確認します。
  • セッション管理 - ユーザのログオン・ログオフ時のタスクを実行します (監査、ファイルシステムのマウント、……)。
  • パスワード管理 - パスワードリセットのためのインターフェースや、同等物を提供します。
メモ
PAM は認可についてはいかなるサービスも提供しません。一般的に、認可はアプリケーションの中で行われます。アプリケーションによってはグループベースの認可をサポートする (グループのメンバーであることで適切な認可を与えられる) ものもあります。このためによく使われる (PAM と比較するとそこまでよく使われてもいませんが) アプローチが、NSS (Name Service Switch) をサポートすることです。NSS は PAM と設計理念の点で似ています。実際、Linux システム上の認可は NSS ライブラリを利用して扱われています。

PAM の背景にある理念

PAM を使っていれば、システム管理者はすぐに PAM が機能するための原則に気づくでしょう。

第一原則はバックエンド独立性です。PAM を意識するアプリケーションは、データベース、LDAP サービス、パスワードファイル、WS-Security が有効な web サービス、あるいは他のまだ発明されていないバックエンドなどの、バックエンドを扱うロジックを含める必要がありません。PAM を使用することで、アプリケーションはバックエンド統合ロジックを自身から切り離します。アプリケーションに必要なのは PAM 関数を呼び出すことだけです。

第二原則は、設定独立性です。管理者は、無数の異なるアプリケーションごとに、認証のための LDAP サーバ連携を設定する方法を学習する必要がなくなります。代わりに、PAM によって提供される同一の設定構造を使用するのです。

最後の原則は、PAM の名前の一部にもなっている通り、プラグイン可能なアーキテクチャであるということです。新しいバックエンドを統合する必要がある場合、管理者に必要なのは、このバックエンドのためのライブラリをインストールし (システム上の適切なディレクトリに配置することによって)、そしてこのモジュールを設定する (多くのモジュールは単一の設定ファイルを使用します) ことです。これが完了した時点で、モジュールはアプリケーションから利用できるようになります。管理者は、このバックエンドを使用するために認証を設定し、通常はアプリケーションを再起動するだけでよいでしょう。

PAM の動作の仕組み

Applications that want to use PAM link with the PAM library (libpam) and call the necessary functions that reflect the above services. Other than that, the application does not need to implement any specific features for these services, as it is all handled by PAM. So when a user wants to authenticate itself against, say, a web application, then this web application calls PAM (passing on the user id and perhaps password or challenge) and checks the PAM return to see if the user is authenticated and allowed access to the application. It is PAM's task underlyingly to see where to authenticate against (such as a central database or LDAP server).

The strength of PAM is that everyone can build PAM modules to integrate with any PAM-enabled service or application. If a company releases a new service for authentication, all it needs to do is provide a PAM module that interacts with its service, and then all software that uses PAM can work with this service immediately: no need to rebuild or enhance those software titles.

設定

PAM のもう一つの重要な側面は、複数モジュールの連鎖をサポートしているということです。次の無名なサービスのための PAM 設定を見てみましょう:

ファイル /etc/pam.d/someservice"someservice" という名前のサービスのための PAM 設定の例
# 認証
auth         required        pam_env.so
auth         required        pam_ldap.so
# アカウント管理
account      required        pam_ldap.so
# パスワード管理
password     required        pam_ldap.so
# セッション管理
session      optional        pam_loginuid.so
session      required        pam_selinux.so close
session      required        pam_env.so
session      required        pam_log.so level=audit
session      required        pam_selinux.so open multiple
session      optional        pam_mail.so

PAM がサポートする 4 つのサービス領域によって、設定ファイルが構造付けられているのが分かるでしょう: 認証、アカウント管理、パスワード管理、そしてセッション管理です。

この設定ファイル内の各セクションは、一つまたは複数の PAM モジュールを呼び出しています。例えば、pam_env.so は後続のモジュールで使用できる環境変数を設定します。PAM モジュールによって提供されるリターンコードと、制御ディレクティブ (上の例では required または optional) を組み合わせて、PAM がどのように処理を継続するかを決定します。

制御ディレクティブ

PAM は以下の制御ディレクティブをサポートしています。

制御 説明
required サービス (認証など) 全体が成功するためには、提供された PAM モジュールは成功しなくてはなりません。PAM モジュールが失敗した場合、サービス自体は拒否されることはすでに確定しているものの、まだ他の PAM モジュールの呼び出しが続きます。
requisite サービス全体が成功するためには、提供された PAM モジュールは成功しなくてはなりません。required とは異なり、PAM モジュールが失敗した場合、直ちに制御が戻され、サービス自体は拒否されます。
sufficient 提供された PAM モジュールが成功すれば、サービス全体が許可されます。残りの PAM モジュールは検査されません。しかしながら PAM モジュールが失敗した場合には残りの PAM モジュールが処理され、この特定の PAM モジュールの失敗は無視されます。
optional この特定の PAM モジュールの成否は、これがスタック上の唯一のモジュールである場合にのみ意味があります。
include 与えられたタイプにマッチする、他の PAM モジュールの設定ファイルの内容を含めます。

モジュールの連鎖を利用することで、複数の認証を行うこと、セッションの開始時に複数のタスクを実行すること、その他様々なことが可能になります。

PAM 設定ファイルを管理する

PAM 設定ファイルはアプリケーションの認証ステップを制御するので、その設定ファイルを安全に管理することは非常に重要です。これらのファイルは通常は /etc/pam.d/ に保存されます。

大企業や、セキュリティが重要なシステムでは、PAM 設定ファイルの変更は適切に監査されるべきです。

PAM モジュール自体が保存される場所 (/lib/security または /lib64/security) についても同様です。

PAM と Gentoo

PAM を条件付きでサポートするアプリケーションは、pam USE フラグを使用するでしょう。Gentoo システムを PAM なしで実行することは (USE="-pam" を設定することで) 可能ではありますが、デフォルトは PAM サポートを有効化して実行します。

When upgrading remote systems it is possible to leave the system inaccessible. To avoid this after an upgrade while being still logged in to the machine:

  1. check that logging is up and running
  2. check necessary configuration updates in /etc/ssh and /etc/pam.d
  3. check news items whether breaking changes were introduced, e.g. PAM related news Item
  4. check that changing passwords works flawlessly, e.g. passwd for root/ any user and cancel before actually changing the password
  5. restart SSH server in case it got updated
  6. check that a new login to the remote machine works

What could happen:

  • without logging errors during the checks cannot be analyzed
  • passwd errors out because of PAM module errors
  • SSH prohibits login because of PAM misconfiguration/ module errors, e.g. plain connection closed
  • password policies changed, e.g. prohibiting root without password

システム設定を解析する方法の例

GDH-gentoo による 2021 年のこのフォーラム投稿では、ユーザのログイン時にどのサービスが /run/user/<uid> ディレクトリを作成しているのか知るために、システムの設定を段階を追ってたどっています。

関連項目

  • PAM (Security Handbook) — Although the default PAM settings in Gentoo are reasonable, there is always room for improvement.
  • PAM/U2F — provides two-factor authentication through a FIDO U2F USB device, allowing users to authenticate at a press of a button against their system.
  • PAM securetty — restricting root authentication with PAM.
  • pam_ssh_agent_auth — is the PAM module that allows a locally installed SSH key to authenticate for sudo
  • Google Authenticator — describes an easy way to setup two-factor authentication on Gentoo.
  • OATH-Toolkit — toolkit for (OTP) One-Time Password authentication using HOTP/TOTP algorithms.
  • YubiKey — a hardware security device that can be used to safely store cryptographic keys, OTP tokens, and challenge response seeds

外部資料