Ubuntu 12.04 VPSで認証を構成するためにPAMを使用する方法

紹介

PAM（プラグイン認証モジュール）は、LinuxおよびUnix系オペレーティングシステムに存在する抽象化レイヤーであり、さまざまなサービス間での認証を可能にするために使用されます。

このシステムは、認証サービスとユーザー認証を必要とするアプリケーションの間の仲介者として構築されており、これにより、これらの2つの層は優雅に統合され、コードを書き換えることなく認証モデルを変更することができます。 これは、モジュールの使用によって実現されます。

このガイドでは、Ubuntu 12.04 VPS上のPAMシステムについて見ていきますが、ほとんどの現代のLinuxディストリビューションは同様の方法で機能するはずです。

舞台裏: PAMの基本概念と仕組み

プラガブル認証の仕組み

私たちが日常的にLinux環境でやり取りする多くの通常のアプリケーションは、実際には内部でPAMを使用しています。

アプリケーションはPAMライブラリのサポートを持って書かれなければなりません。システム上でPAMを何らかの形で使用できるアプリケーションのリストを取得するには、次のように入力します:

ldd /{,usr/}{bin,sbin}/* | grep -B 5 libpam | grep '^/'

/bin/login:
/bin/su:
/sbin/mkhomedir_helper:
/sbin/pam_tally2:
/usr/bin/chfn:
/usr/bin/chsh:
/usr/bin/passwd:
/usr/sbin/atd:
/usr/sbin/chpasswd:
/usr/sbin/cron:
/usr/sbin/newusers:
/usr/sbin/sshd:

PAM機能の特定のアプリケーションを確認するには、次のように入力します:

 ldd $ (which prog_name) | grep libpam 

もし何かを返すなら、それはPAMを使用できる。

ご覧の通り、多くの一般的なユーティリティやツールは、実際にそのタスクを実行するためにPAMを仲介として使用しています。

PAM組織

LinuxのPAMのバージョンは、モジュールの機能をプロセスのどの部分に関与しているかに応じて異なるカテゴリに分けます。以下はカテゴリの簡単な説明です:

• 認証機能: 認証モジュールはユーザーの認証資格情報を検証します。これは、ユーザーが有効な資格情報を提供できるかどうかを確認することを意味します。

• アカウント機能: これらのモジュールは、サインインを試みているアカウントが現在要求しているリソースにアクセスできるかどうかを決定する責任があります。PAMは、事前に定められた基準に基づいてユーザーを拒否または許可する制御を指定することを可能にします。

• セッション機能: これらのモジュールは、ユーザーがログインまたはログオフした後に構築されて解体される環境を確立します。 セッションファイルは、環境を準備するために実行する必要のあるコマンドを決定できます。

• パスワード機能: これらのモジュールは、さまざまなサービスの認証詳細を更新する責任があります。サービスのパスワードを変更する必要がある場合、このモジュールはサービスとの通信を支援し、正しい値を修正することができます。

これらのモジュールカテゴリの最初の2つは、プログラムがPAMを使用して認証に成功するたびに参照されます。セッションモジュールは、最初の2つの後に必要に応じて実行されます。パスワードモジュールはオンデマンドでアクセスされます。

ディレクトリ構造に関して、PAM 設定ファイルは/etc/pam.dに保存されています:

ls /etc/pam.d

atd       chsh            common-password                cron      other   su
chfn      common-account  common-session                 login     passwd  sudo
chpasswd  common-auth     common-session-noninteractive  newusers  sshd

このディレクトリには、一般的にPAM認証をリクエストする各アプリケーションのための設定ファイルがあります。アプリケーションがPAMを呼び出しますが、関連する設定ファイルがない場合は、「その他」の設定ファイルが適用されます。

設定ファイルの中には、通常、「common-」で始まる設定ファイルを含めるための呼び出しがあります。これらは、ほとんどの状況で適用されるべき一般的な設定ファイルです。

設定ファイルで参照されているモジュールは、このコマンドで見つけることができます:

ls /lib/*/security

pam_access.so     pam_keyinit.so    pam_permit.so      pam_tally.so
pam_debug.so      pam_lastlog.so    pam_pwhistory.so   pam_time.so
pam_deny.so       pam_limits.so     pam_rhosts.so      pam_timestamp.so
pam_echo.so       pam_listfile.so   pam_rootok.so      pam_umask.so
. . .

このディレクトリを見て、どのようなモジュールが利用可能かを確認してください。ほとんどすべてのモジュールにはマニュアルページがあり、その使用方法を説明しています。

PAMが認証を評価する方法

アプリケーションが認証のためにPAMシステムにクエリを送ると、PAMは関連するPAM設定ファイルを読み込みます。

設定ファイルには、PAMモジュールのリストとそれらの扱い方が含まれています。各モジュールは順番に呼び出され、モジュールへの各呼び出しは成功または失敗の結果を生成します。

これらの値に基づいて、設定ファイルは、呼び出し元に「認証成功」のメッセージを返すべきか、認証失敗メッセージを送るべきかを決定します。

設定は、呼び出されたモジュールからの最初の失敗の返却時に失敗するか、代替ポリシーを設定することができます。例えば、システムはLDAPユーザーの認証を許可する場合があります。もしそれが失敗した場合、ローカルユーザーのリストに対して確認することができます。

各構成ファイルの行は、行の評価が構成ファイルの残りの部分をスキップさせない限り、上から下に評価されます。

ポリシーラインの読み方

設定ファイルの各行は、次の構文を含み、各フィールドは空白で区切られています。

[service] type control module-path [module-arguments]

/etc/pam.d 内にあるファイルはサービスフィールドを除外し、代わりに対象となるアプリケーションの名前で構成ファイルを命名します。pam.d ディレクトリが存在しない場合は、代わりに /etc/pam.conf ファイルが必要で、その関連アプリケーションは各行の先頭にリストアップする必要があります。

タイプは提供されるサービスの種類です。これは上記の4つのカテゴリー（認証、アカウント、パスワード、セッション）のうちの1つです。

Controlは、モジュール呼び出しの戻りステータスを受け取ったときに実行されるアクションを指定します。それはこれらの値のいずれかであることができ（さらに複雑な構文も取ることができますが、ここでは取り上げません）:

• 必須: モジュール呼び出しが失敗した場合、これは認証失敗につながります。ただし、指定された他のモジュールはまだ呼び出されます。

• 必須: これは必要とまったく同じように振る舞いますが、残りのモジュールを呼び出すのではなく、すぐに認証失敗を引き起こします。

• 十分な: この制御は、このラインが成功した場合（すでに必要なモジュールの失敗がなかった場合）、認証は残りのモジュールを実行せずにすぐに成功として返されることを意味します。このラインの失敗は、単に次のモジュール呼び出しにスキップします。

• 任意: これらの行の成功または失敗は、これらがその種類の唯一のモジュール呼び出しでない限り、全体的な認証の成功または失敗には影響しません。

• 含む: この行は、特定のタイプの行が別の構成スクリプトから読み込まれるべきであることを示しています。これは、しばしば「共通-」ファイルを参照するために使用されます。

• サブスタック: これはインクルードに似ていますが、失敗や成功は全体のファイルの終了を引き起こさず、サブスタックだけの影響にとどまります。

モジュールパス は呼び出す PAM モジュールの名前です。

モジュール引数は、モジュールに渡されるオプションのパラメータです。これらは、モジュールが成功した場合にどのアクションを取るべきかを知るために必要な場合があります。

個別のファイルは、以下の構文を使用して確認しなければならない他のファイルを参照する場合もあります。

 @include config_file 

これは全体の設定ファイルを読み込みます。これは「インクルード」制御タイプとは異なり、「インクルード」制御タイプは同じタイプの行のみを読み込みます。

例の構成を検討する

クライアントがどのように設定されているかを、/etc/pam.d ディレクトリ内のいくつかの例をチェックすることで把握できます。

「atd」というスケジューリングデーモンの認証要件を説明するファイルを開いてください。

less /etc/pam.d/atd

auth	required		pam_env.so
@include common-auth
@include common-account
@include common-session-noninteractive
session		required	pam_limits.so

最初の行は「pam_env」モジュールを呼び出します。マニュアルページを見ると、このモジュールは環境変数の一部を設定するために使用されていることがわかります。これらの変数はデフォルトで/etc/security/pam_env.confに保存されます。これは「必須」であり、このモジュールが「失敗」を返すと、全体の設定が失敗しますが、そのようなことは起こらないはずです。

次の3行は、それぞれの役割に対処するために「common-auth」、「common-account」、および「common-session-noninteractive」ファイルで読み取られます。

最後の行は「pam_limits」モジュールを呼び出します。このモジュールは、/etc/security/limits.confファイルまたは/etc/security/limits.d/ディレクトリをチェックします。これにより、同時にサービスを使用できるユーザーの数に制限を課すことができるほか、他のことにも利用できます。

参照されているファイルを見れば、行われているすべてのチェックについてより完全な理解を得ることができます。

共通認証ファイルの確認

情報を圧縮するためにファイルからコメントを削除しました。

less /etc/pam.d/common-auth

auth	[success=1 default=ignore] 		pam_unix.so nullok_secure
auth	requisite						pam_deny.so
auth	required						pam_permit.so
auth	optional						pam_ecryptfs.so unwrap

最初の行はまだ私たちが話し合ったことではありません。これは、“pam_unix” モジュールを呼び出していることを示しています。このモジュールは、“/etc/nsswitch.conf” ファイルを介して設定された標準の unix 認証を提供します。通常、これは /etc/passwd および /etc/shadow ファイルをチェックすることを意味しますが、期待どおりです。

unuxモジュールに渡される「nullok_secure」引数は、/etc/securettyファイルのログイン情報が確認できる限り、パスワードのないアカウントは問題ないことを指定しています。

「[success=1 default=ignore]」を持つ制御フィールドは、この例の奇妙な部分です。それは簡略化された「必須」、「十分な」などのパラメータを置き換え、より詳細な制御を可能にします。

この場合、モジュールが成功を返すと、次の「1」行をスキップします。モジュールの他のすべての返値を処理するデフォルトケースは、その行を無視して次に進む結果になります。

2 行目 は「必須」の制御値を持っており、これが失敗すると、全体の設定が即座に失敗を返します。また、「pam_deny」モジュールも呼び出されており、すべての呼び出しに対して失敗を返します。

これは常に失敗することを意味します。唯一の例外は、この行がスキップされるときで、それは最初の行が成功して戻るときに起こります。

3行目は必須で、“pam_permit”モジュールを呼び出します。これは、毎回成功を返します。これは単に現在の“合格/不合格”の記録をこの時点でリセットし、以前の奇妙な値がないことを確認します。

第四行はオプションとしてリストされており、“pam_ecryptfs”モジュールを“unwrap”オプションで呼び出します。これは、提供されたパスワードを使用してパスフレーズを解除し、その後プライベートディレクトリをマウントするために使用されます。これはこの技術を使用する場合にのみ関連があるため、オプションとされています。

共通アカウントファイルの確認

「atd」設定で参照されている次のファイルを見ていきます。再度、簡潔さのためにコメントは削除します。

less /etc/pam.d/common-account

account [success=1 new_authtok_reqd=done default=ignore] 	pam_unix.so
account	requisite		pam_deny.so
account	requisite		pam_permit.so

このファイルのほぼすべては「common-auth」ファイルのものと似ています。最初の行は「pam_unix」モジュールによるアカウントチェックを要求します。

モジュールは、コールの「タイプ」に応じて異なる機能を実行できます。アカウントコールの場合、pam_unixはアカウントが期限切れでなく、時間ベースのログイン制限に管理されていないことを確認します。

もしそれが通過すれば、下にある「pam_deny」呼び出しをスキップし、最後に許可ルールを処理します。一方、失敗した場合は、拒否行に移動して失敗で終了します。

共通セッション非インタラクティブファイルをチェックする

次のセクションでは、非対話型プログラムや環境のセッションチェックを提供します。

less /etc/pam.d/common-session-noninteractive

session [default=1] 		pam_permit.so
session	requisite			pam_deny.so
session	required			pam_permit.so
session	optional			pam_umask.so
session	required			pam_unix.so
session	optional			pam_ecryptfs.so unwrap

最初の3行は奇妙に見えるかもしれません。現時点ではプログラムの流れを理解できるはずですが、これらはおそらく恣意的で冗長に見えるでしょう。最初の行は常に成功し、次の行はスキップされ、3行目は常に成功します。

彼らはこのようになっているのは、多くのPAM設定が自動的に生成されており、追加のPAM対応認証方法が利用可能になったときに、より重要なルールを提供するために変更されるからです。これは、新しいルールを挿入して後でプログラムの流れに影響を与えることができる枠組みを作るだけです。

四行目は「pam_umask」モジュールへの呼び出しで、オプションとしてマークされています。これはセッションのファイル作成マスクを設定します。関連するumaskの場所を見つけるために、いくつかの異なるファイルロケーションをチェックします。

5行目は再びpam_unixモジュールへの必須呼び出しです。この呼び出しは「セッション」タイプであるため、unixモジュールは再び異なる動作をします。この場合、システムのユーティリティを使用したログ記録を実装します。

最後の行は再び「pam_ecryptfs」呼び出しです。これは「auth」ファイルに配置されているのと同様の機能を果たします。

結論

PAMは最初は非常に習得が難しい場合があります。しかし、システムがどのように機能し、異なるコンポーネントがどのように結びついているかを基本的に理解することは、健全な認証手順を開発するために不可欠です。

PAMルールの設定に関して全てを理解していなくても、コンピュータの不正使用を防ぐためにどのようなシステムが整備されているかを知っておくことは良いことです。

新しい認証方式を実装する際、特にLDAPのようなPAMを理解することが重要です。認証方式は、完全にまたは条件付きで新しいシステムを使用するように変更する必要があります。