開発者ドキュメント

Ubuntu12.04VPSでPAMを使用して認証を構成する方法

getdocs

ステータス：非推奨

この記事では、サポートされなくなったバージョンのUbuntuについて説明します。 現在Ubuntu12.04を実行しているサーバーを運用している場合は、サポートされているバージョンのUbuntuにアップグレードまたは移行することを強くお勧めします。

理由：
Ubuntu 12.04は2017年4月28日に保守終了（EOL）に達しました and no longer receives security patches or updates. This guide is no longer maintained.

代わりに参照してください：このガイドは参照として役立つ場合がありますが、他のUbuntuリリースでは機能しない場合があります。 可能な場合は、使用しているUbuntuのバージョン用に作成されたガイドを使用することを強くお勧めします。 ページ上部の検索機能を使用して、より新しいバージョンを見つけることができます。

序章

PAM 、またはPluggable Authentication Modulesは、さまざまなサービス間の認証を可能にするために使用される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は、プロセスのどの部分に関与しているかに応じて、モジュールの機能をさまざまなカテゴリに分類します。 カテゴリの簡単な説明は次のとおりです。

これらのモジュールカテゴリの最初の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モジュールのリストとそれらの処理方法が含まれています。 各モジュールは順番に呼び出され、モジュールへの各呼び出しは成功または失敗の結果を生成します。

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

呼び出されたモジュールから最初の障害が戻ったときに構成が失敗するか、代替ポリシーを構成できます。 たとえば、システムはLDAPユーザーに認証を許可する場合があります。 それが失敗した場合は、ローカルユーザーのリストと照合する場合があります。

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

ポリシーラインの読み方

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

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

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

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

Control は、モジュール呼び出しの戻りステータスを受信したときに実行されるアクションを指定します。 これらの値のいずれかを指定できます（さらに、ここでは説明しない、より複雑な構文を使用することもできます）。

Module-path は、呼び出すpamモジュールの名前です。

Module-arguments は、モジュールに渡されるオプションのパラメーターです。 モジュールが成功した場合に実行するアクションを知るために、これらが必要になる場合があります。

個々のファイルは、次の構文を使用してチェックする必要がある他のファイルを参照する場合もあります。

 @含む config_file

これにより、構成ファイル全体が読み込まれます。これは、同じタイプの行のみを読み込む「include」コントロールタイプとは異なります。

構成例の調査

/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/ディレクトリをチェックします。 これは、とりわけ、サービスを同時に使用できるユーザーの数に制限を適用するために使用できます。

参照されているファイルを確認することで、実行されているすべてのチェックをより完全に理解できます。

common-authファイルを確認する

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

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

最初の行はまだ説明していません。 「/etc/nsswitch.conf」ファイルを介して構成された標準のUNIX認証を提供する「pam_unix」モジュールを呼び出していることがわかります。 通常、これは、予想どおり、/etc/passwdおよび/etc/shadowファイルをチェックすることを意味します。

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

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

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

2行目の制御値は「必須」です。これは、失敗した場合、構成全体がすぐに失敗を返すことを意味します。 また、「pam_deny」モジュールを呼び出します。このモジュールは、呼び出しごとに失敗を返します。

これは、これが常に失敗することを意味します。 唯一の例外は、この行がスキップされた場合です。これは、最初の行が正常に戻ったときに発生します。

3行目が必要で、「pam_permit」モジュールを呼び出します。このモジュールは毎回成功を返します。 これにより、この時点で現在の「合格/不合格」レコードがリセットされ、以前の奇妙な値がないことが保証されます。

4行目はオプションとしてリストされており、「unwrap」オプションを使用して「pam_ecryptfs」モジュールを呼び出します。 これは、提供されたパスワードを使用してパスフレーズをアンラップするために使用されます。このパスワードは、プライベートディレクトリのマウントに使用されます。 これは、このテクノロジーを使用する場合にのみ関係するため、オプションです。

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

「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」呼び出しをスキップし、最後に許可ルールを処理します。 一方、失敗した場合は、拒否ラインに移動し、失敗して終了します。

common-session-noninteractiveファイルを確認する

次のセクションでは、非対話型プログラムまたは環境のセッションチェックについて説明します。

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対応認証方式が使用可能な場合に、より実質的なルールを提供するように変更されるため、これらはこの方法です。 これは、後でプログラムフローに影響を与えるために新しいルールを挿入できるフレームワークを作成するだけです。

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

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

最後の行は、再び「pam_ecryptfs」呼び出しです。 「auth」ファイルへの配置と同様の機能を実行します。

結論

PAMは、最初に習得するのが非常に複雑になる可能性があります。 ただし、システムがどのように機能し、さまざまなコンポーネントをどのようにリンクするかについての基本的な理解は、適切な認証手順を開発するために不可欠です。

PAMルールの構成に関するすべてを理解しているとは限りませんが、コンピューターの不正使用を防ぐためにどのシステムが導入されているかを知っておくとよいでしょう。

LDAPなどの新しい認証スキームを実装する場合は、PAMを理解することが特に重要です。 新しいシステムを完全に、または条件付きで使用するには、認証スキームを切り替える必要があります。

ジャスティン・エリングウッド
モバイルバージョンを終了