今日は、Linuxのユーザ認証で使われているPAMについて、ちょっとだけ触ってみます。
ちなみに、PAMで調べると、RedHatの公式ドキュメント以外は、2000年代前半くらいの記事がヒットします。古くからある技術のようです。
もくじ
１．PAMとは
１．PAMとは
PAM(Pluggable Authentication Modules)とは、Linuxやアプリケーションでユーザ認証を行うためのAPI。
PAMは個々のアプリケーションから独立して、ライブラリや各種モジュールを備え、
LinuxOSやアプリケーションは、PAMを利用することでユーザ認証を行うことができる。
特によく使うプログラムでいうと、Linuxのユーザログイン（login）や、ユーザ切替（su）でも、PAMの仕組みが利用されている。
２．PAMを使ったユーザログインの流れ
ここでは、PAMを利用した、ユーザログインの流れを詳しく見ていきたい。
①ログイン要求が、利用者から送られる
３．PAM関連のファイルを見てみる
「２．PAMを使ったユーザログインの流れ」で説明したようなログインの流れや、その他各種ユーザ認証・管理において、
どのPAMモジュールを利用するかや、モジュール実行後の処理決定方式を設定するため、
設定ファイルが用意されている。
設定ファイルおよびディレクトリの配置場所は以下である。
ディレクトリ： /etc/pam.d
ファイル： /etc/pam.conf
基本は/etc/pam.confに設定するが、/etc/pam.dディレクトリが存在するときは、その配下にある設定ファイルが優先される。
なお、CentOS8では、デフォルトで/etc/pam.d配下に多数のファイルが配置されており、
/etc/pam.confファイルは中身の記述はあるもののすべてコメントアウトされていた。
そのため基本的には、/etc/pam.d配下を気にしておけば良さそうである。
ここで、PAM設定ファイルの中でもよく使うと思われる、/etc/pam.d/loginファイルの中身を確認してみる。
/etc/pam.d/loginは、ユーザ認証・管理の中でも、特にログインに関する設定を行うためのファイルである。
#%PAM-1.0
auth substack system-auth
auth include postlogin
account required pam_nologin.so
account include system-auth
password include system-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_loginuid.so
session optional pam_console.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session required pam_selinux.so open
session required pam_namespace.so
session optional pam_keyinit.so force revoke
session include system-auth
session include postlogin
-session optional pam_ck_connector.so
PAMのファイルの中身は、上記/etc/pam.d/loginファイルのように、１行あたり３つまたはそれ以上のパラメータが書かれているような構造となっている。
第一パラメータ（auth、accountなど）部分には、モジュールタイプ、またはPAMインタフェースと呼ばれる、認証アクションの種別名が渡される。
モジュールタイプには以下の４つがある。
| モジュールタイプ | 説明 |
|---|---|
| auth | ユーザ認証（パスワードの検証） |
| account | アクセスが許可されたかを確認 |
| password | ユーザのパスワード変更 |
| session | ユーザセッションの設定・管理 |
２で挙げたログイン認証の場合、モジュールタイプはauthとなる。
各モジュールタイプによって、実行できるPAMモジュールが決まっている。
実際に実行するPAMモジュールは、第三パラメータで渡されている。
なお、第四パラメータ以降も指定されている場合は、第三パラメータのPAMモジュールに対して渡される引数が定義されているということである。
ややこしいのが、モジュールタイプ（第一パラメータ）と実行モジュール（第三パラメータ）の関係は、
１：多ではなく、多：多であること。
例えば、モジュールタイプがauthで実行モジュールがsystem-authであり、
モジュールタイプがaccountで、実行モジュールは同じくsystem-authであるなど。
同じモジュールを実行していても、タイプによって実際の挙動が変わってくることになる。
話を設定ファイルに戻すと、
各行の第二パラメータ（substack, includeなど）部分には、処理制御フラグが渡される。
処理制御フラグは、第三パラメータの実行モジュールの処理結果を踏まえて、次のアクションを決めるための役割を担っている。フラグの種類は以下の通り６種類ある。
| 処理制御フラグ | 説明 |
|---|---|
| required | 認証を継続するには、モジュール結果が成功している必要がある。 ただし失敗しても、後続に実行予定のモジュール処理が全て終わるまでは、 利用者に結果が通知されない。 |
| requisite | 認証を継続するには、モジュール結果が成功する必要がある。 失敗した場合、ユーザーに直ちに通知される。 通知メッセージには、失敗したモジュール処理に関する情報も記載されるため、 正規利用者や開発者にとって分かりやすい一方、 攻撃者へも、どのようなモジュールで認証をしているかを知らせることになる。 |
| sufficient | モジュール結果は失敗しても無視される。 ただし結果が成功しており、 かつ required フラグが付いたモジュールがそれまでに失敗していなければ、さらに他のモジュール処理があってもユーザ認証される。 |
| optional | モジュール結果は無視される。 他のモジュール処理がないような処理のときに、認証成功のために 便宜的に必要となるフラグ。 |
| include | モジュール結果の処理には関係しないフラグ。 第三パラメータで指定されたPAMモジュール内のパラメータのうち、 第一パラメータで指定されたモジュールタイプと合致するもの全てを、 パラメータに追加する。 例： /etc/pam.d/login に以下が記載されていた場合 session include system-auth →system-authというPAMモジュールファイルに記載のある各行のうち、 モジュールタイプがsessionの行すべてを、 /etc/pam.d/loginにも適用するという意味になる。 |
| substack | includeとほぼ同じだが、 includeでは第三パラメータで指定したPAMモジュールの記載内容を そのまま持ってくるだけなのに対し、 substackでは指定したPAMモジュール内で処理を実行し、 結果だけを持ってくるという違いがある。 |
設定ファイルの構造自体はかなりシンプルだが、
その裏で動いているPAMモジュールはかなり複雑そうである…。
４．PAMファイル設定の注意点
今回は以上！