認証の近代化：GNU GuileによるLinux-PAMモジュールの作成

30年以上にわたり、Linux-PAM (Pluggable Authentication Modules) はLinuxシステムの認証の基盤として機能してきました。その設計は当時としては画期的であり、suやloginのようなセキュリティ関連のアプリケーションが、ポリシーが変更されるたびに再コンパイルを必要とすることなく、一貫したポリシーに従うことを可能にしました。しかし、共有Cオブジェクトへの依存は、カスタムモジュールの作成とメンテナンスを煩雑で不透明なものにすることがよくあります。

Guile-PAMは現代的な代替手段として登場し、システム管理者がSchemeのダイアレクトであるGNU Guileを使用して、PAMモジュールを記述、設定、およびメンテナンスすることを可能にします。低レベルのPAM APIと高レベルの解釈言語の間のギャップを埋めることで、Guile-PAMは認証ロジックを静的なコンパイル済みバイナリから、柔軟で読みやすいスクリプトへと変貌させます。

Guile-PAMのアーキテクチャ

その核心において、Guile-PAMは特別に作成された共有オブジェクトpam_guile.soを介して動作します。このオブジェクトはゲートウェイとして機能し、認証タスクを処理するためにGNU Guileスクリプトを呼び出します。このアーキテクチャにより、3つの異なるレベルの統合が可能になります：

タスク固有のモジュール: pam_guile.soを標準的なLinux-PAM共有オブジェクトとして使用し、Guileで単一の特定のタスクを実行する。
サービスの置換: pam_guile.soを唯一の共有オブジェクトとし、すべてのロジックをGuile内で処理することで、PAMレシピ（特定のサービス）全体を置換する。
システム全体のオーケストレーション: /etc/pam.d内のすべてのサービスをpam_guile.soに置き換え、レシピの選択とロジックの両方をGuile環境へと実質的に移動させる。

"Pamdas"の理解

Guile-PAMにおいて、ロジックの基本単位はPamda（PAMとLambdaの合成語）です。Pamdaは、以下のシグネチャを持つ匿名手続きです：

(lambda (action handle flags options) ...)

Action: 6つのシンボルのうちの1つ（例：pam_sm_authenticate, pam_sm_open_session）で、PAMのエントリポイントを表す。
Handle: ユーザー名や会話関数などの内部PAMデータへのアクセスを提供する不透明な変数。
Flags: 整数ビットマスク。
Options: サービス定義から渡される文字列のリスト。

PAMスタックの再実装

Guile-PAMの最も強力な機能の一つは、Linux-PAMスタックをSchemeで完全に再実装していることです。Linux-PAMの静的な設定ファイルに依存する代わりに、開発者は「ゲート」と「プラン」をプログラム的に定義できます。

ゲートとプラン

A gate 手続きはpamdaをラップし、それにプラン（required, optional, sufficient, または requisite）を割り当てます。次に、stack 手続きがこれらのゲートを順番に評価します。

従来のセットアップから移行する場合、Guile-PAMはcontrol-string->planを提供しており、これは標準的なLinux-PAMのコントロール文字列（例：success=ok ignore=ignore default=bad）を直接Guile-PAMのプランへと変換します。

ハイブリッドスタック

Guile-PAMは、既存のCベースのモジュールを完全に放棄することを要求しません。call-shared-objectを使用することで、Guile-PAMスタックはレガシーな.soファイルを呼び出すことができます。多くのレガシーモジュールは、実装していないアクションに対して呼び出された際にPAM_SERVICE_ERRを返すため、安定性の問題を防止するために、Guile-PAMは開発者が#:implementsキーワードを使用して、共有オブジェクトがどの正確なアクションを実装しているかを指定できるようにしています。

高度なユースケース：単純な認証を超えて

Guile-PAMは、システムへのアクセス権を持つ解釈言語であるため、標準的なPAMモジュールでは困難または不可能なことが実現可能です。

例：ユーザーレベルのマウント

A primary motivation（主要な動機）は、rootではなく実際のユーザーとしてボリュームをマウントする能力でした。pam_mount.soが存在しますが、通常はrootとしてマウントするため、FUSEフォルダやkerberized NFSv4では失敗します。

Guile-PAMは、pam_sm_authenticate中に受け取ったトークンを保存し、その後pam_sm_open_session中にそれを使用して、シークレットをgocryptfsのようなユーザー空間ツールにパイプで渡し、ログインプロセス中にホームディレクトリをユーザーとしてマウントする、というワークフローを可能にします。

セキュリティとパフォーマンスの考慮事項

認証ロジックを解釈言語に移行することは、特定の考慮事項をもたらします：

セキュリティ

可読性: 著者は、Schemeコードは一般的にCよりも監査が容易であり、ピアレビューの可能性を高めると主張しています。
注入リスク: 攻撃を防ぐため、開発者は未知の入力に対してGuileのread手続きを使用しないよう注意喚起されています。
環境の隔離: pam_guile.soは、不正なモジュール置換を防ぐために、GUILE_LOAD_PATHのような環境変数を使用します。

パフォーマンス

実用的なテストでは、Guile-PAMは適切な速度で動作することが示されています。興味深いことに、著者は、認証において極端な速度は必ずしも目標ではないと述べています。これは、ブルートフォース攻撃を阻止するために、意図的な遅延が組み込まれていることが多いためです。

実装上の注意点

ユーザーは、Guile-PAMが現在alpha stage（アルファ版）であることを認識しておくべきです。成熟したLinux-PAMと比較して、重要な挙動の差異があります：

Action Grouping: Linux-PAMは特定の特定のアクション（authやsetcredなど）をグループ化し、最初のものがPAM_IGNOREを返した場合に2番目をスキップすることがあります。Guile-PAMの(pam stack)実装は、すべてのアクションに対してすべてのモジュールを評価します。
Skip Counts: 明示的なスキップカウントを持つレガシーな命令セットにおいて、Unlocked Guile-PAMスタックは常に結果を取得します。一方、Linux-PAMの副作用はアクションによって異なります。

結論

Guile-PAMは、より透明で柔軟なシステム管理へのシフトを表しています。認証をバイナリの塊の設定ではなく、プログラム可能なロジックの問題として扱うことで、新しい分岐戦略や、OpenBSDスクリプトのような他のフリーソフトウェア・システムとのより深い統合への道を開きます。GNU Guixを使用している場合、その統合はさらにシームレスであり、認証スタック全体をシステム構成の中で定義することが可能になります。