第4章 認証とアクセスの制御

PAM と NSS がアクセスする注目すべき設定ファイルを次に記します。

パスワード選択の制限は pam_unix(8) と pam_cracklib(8) モジュールで実装されています。それらは引数を使って設定します。

	ヒント
	PAM モジュールはファイル名のサフィクスとして ".so" を使います。

集中化された軽量ディレクトリーアクセスプロトコル (LDAP) を採用することで多くのネットワーク上の Unix 的や非 Unix 的システムを運営する、現代的な集中システム管理が実現できます。軽量ディレクトリーアクセスプロトコルのオープンソース実装は OpenLDAP ソフトウエアーです。

LDAP サーバーは、libpam-ldap と libnss-ldap パッケージで提供される PAM と NSS を使うことで Debian システムにアカウント情報を提供します。この実現ためにはいくつかの設定が必要です (著者は本設定を使っていないため、次の情報は完全に二次情報です。ご理解の上お読み下さい。)。

libpam-doc パッケージで提供される pam_ldap.conf(5) や "/usr/share/doc/libpam-doc/html/" や glibc-doc パッケージで提供される "info libc 'NameServiceSwitch'" といった文書を参照下さい。

同様に、これに代わる集中化されたシステムは他の方法を使っても設定できます。

これは Richard M. Stallman が書いた昔の "info su" の最後に書かれていた有名な文言です。ご心配は無用です。現在 Debian にある su は PAM を使っているので "/etc/pam.d/su" の中の "pam_wheel.so" の行をエネーブルすることで su を使えるのを root グループに限定できます。

# here are the per-package modules (the "Primary" block)
password	requisite			pam_cracklib.so retry=3 minlen=8 difok=3
password	[success=1 default=ignore]	pam_unix.so obscure use_authtok try_first_pass yescrypt
# here's the fallback if no module succeeds
password	requisite			pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password	required			pam_permit.so
# and here are more per-package modules (the "Additional" block)
password	optional	pam_gnome_keyring.so 
# end of pam-auth-update config

多くのトランスポーテーションレイヤーサービスはパスワード認証も含めて暗号化せずにメッセージをプレーンテキストで通信します。途中で傍受されかねないインターネットの荒野を経由して暗号化せずパスワードを送ることは非常によくない考えです。これらに関しては、"トランスポーテーションレイヤーセキュリティー"(TLS) もしくはその前身の "セキュアーソケットレイヤー" (SSL) で暗号化することでパスワードを含むすべての通信をセキュアーにしてサービスができます。

暗号化には CPU タイムがかかります。CPU に友好的な代替方法として、POP には "パスワードを認証されたポストオフィスプロトコル "(APOP) や SMTP や IMAP には "チャレンジレスポンス認証メカニズム MD5" (CRAM-MD5) といったセキュアーな認証プロトコルでパスワードのみを保護しつつ通信はプレーンテキストですることもできます。(最近メールクライアントからメールサーバーにインターネット経由でメールメッセージを送る際には、CRAM-MD5 で認証をしたのちネットワークプロバイダーによるポート25 ブロッキングを避けて従来の SMTP ポート25 の代わりにメッセージサブミッションポート587 を使うことがよく行われます。)

セキュアーシェル (SSH) プログラムはセキュアーな認証とともにインセキュアーなネットワークを通過したお互いに信頼し合っていないホスト間のセキュアーで暗号化された通信を可能にします。OpenSSH クライアント ssh(1) と OpenSSH デーモン sshd(8) から成り立っています。SSH はポートフォーワーディング機能を使い POP や X のようなインセキュアープロトコルの通信をインターネット経由でトンネルするのに使えます。

クライアントは、ホストベースド認証、公開鍵認証、チャレンジレスポンス認証、パスワード認証を使って認証をとろうとします。公開鍵認証を利用すると、リモートからのパスワード無しログインができるようになります。「リーモートアクセスサーバーとユーティリティー (SSH)」を参照下さい。

たとえ、セキュアーシェル (SSH) やポイントツーポイントトンネリングプロトコル (PPTP) サーバーのようなセキュアーサービスを走らせる場合でも、ブルートフォースのパスワード推測等による侵入の可能性は残っています。次のようなセキュリティーのためのツールとともに、ファイアーウォールポリシー (「Netfilter インフラ」を参照下さい) を使うのはセキュリティー状況を向上させることが期待できます。

あなたの機器に他人が root 権限を持ってアクセスするのを阻止するには、次のアクションが必要です。

• ハードディスクへの物理的アクセスを阻止

• UEFI/BIOS をロックして、リムーバブルメディアからのブートを阻止

• GRUB のインタラクティブセッションのパスワードを設定

• GRUB のメニュー項目編集に施錠

ハードディスクへの物理的アクセスがあれば、パスワードをリセットすることは次の手順を使うと比較的簡単です。

1. ハードディスクを CD からブート可能な UEFI/BIOS のついた PC に移動します。

2. レスキューメディア (Debian ブートディスク、Knoppix CD、GRUB CD、…) でシステムをブートします。

3. ルートパーティションを読出し / 書込みアクセスでマウントします。

4. ルートパーティションの "/etc/passwd" を編集し、root アカウントの2番目の項目を空にします。

grub-rescue-pc のブート時に GRUB のメニュー項目を編集可能 (「2段目: ブートローダー」を参照下さい) なら、次の手順を使えてさらに簡単です。

これで、システムの root シェルにパスワード無しに入れるようになりました。

この様な懸念を回避できる唯一の合理的なソフトウエアー的解決法は、dm-crypt と initramfs (「データー暗号化ティップ」 参照下さい) をつかう、ソフトウエアー暗号化されたルートパーティション (もしくは "/etc" パーティション) を使うことです。でも、パスワードがシステムのブート毎に必要になってしまいます。

sudo はシステム管理者がユーザーに制限付きの root 権限を与え、その root 活動を記録するように設計されたプログラムです。sudo は通常のユーザーのパスワードだけが必要です。sudo パッケージをインストールし、"/etc/sudoers" の中のオプションを設定することによりアクティベートして下さい。"/usr/share/doc/sudo/examples/sudoers" や 「sudo の設定」 の設定例を参照下さい。

単一ユーザーシステムにおける私の sudo の使い方 (「sudo の設定」を参照下さい) は自分自身の失敗からの防衛を目指しています。sudo を使うことは、常に root アカウントからシステムを使うよりは良い方法だと個人的には考えます。例えば、次は "some_file" の所有者を "my_name" に変更します。

$ sudo chown my_name some_file

root のパスワード (自分でシステムインストールをした Debian ユーザーなら当然知っています) を知っていれば、どのユーザーアカウントからいかなるコマンドも "su -c" とすれば root もとで実行できます。

PolicyKit は Unix系オペレーティングシステムにおけるシステム全体の特権を制御するオペレーティングシステム構成要素です。

新しいGUIアプリケーションは、特権プロセスとして実行するように設計されていません。それらは、PolicyKitを経由し管理操作を実行する特権プロセスに話しかけます。

PolicyKitは、このような操作をDebianシステム上のsudoグループ所属のユーザーアカウントに限定します。

polkit(8)を参照下さい。

システムのセキュリティーのためにできるだけ多くのサーバープログラムを無効とするのは良い考えです。このことはネットワークサーバーの場合は決定的です。直接デーモンとしてであれスーパーサーバープログラム経由であれアクティベートされている使っていないサーバーがあることはセキュリティーリスクと考えられます。

sshd(8) 等の多くのプログラムが PAM を使ったアクセスコントロールを使っています。サーバーサービスへのアクセスを制限するには多くの方法があります。

「システム管理」 と「PAM と NSS によってアクセスされる設定ファイル」と「Netfilter インフラ」 を参照下さい。

Linux カーネルは進化していて、伝統的な UNIX 実装には見当たらないセキュリティー機能をサポートします。

Linux は、伝統的な UNIX アトリビュートを拡張する拡張アトリビュートをサポートします (xattr(7) を参照下さい)。

Linux は、伝統的にスーパーユーザーに紐付けられた特権を capabilities(7) として知られた、独立に有効化や無効化できる、別個の単位に分割します。

Linux セキュリティーモジュール (LSM) フレームワークは、新規のカーネル拡張により接続される各種セキュリティーチェックのためのメカニズムを提供します。例えば:

このような拡張は特権モデルを通常の Unix ライクのセキュリティー モデル ポリシーより厳しく引き締められるので、ルートの力も制約されるかもしれません。kernel.org にある Linux セキュリティー モデル (LSM) フレームワーク文書を読むことをおすすめします。

Linux namespaces は、namespace 内のプロセスから見たらプロセスがグローバルリソースの中でそれ自身のインスタンスがあるようにグローバルステムリソースを抽象化し包み込んでいます。グローバルリソースの変更は namespace のメンバーである他のプロセスからは見えますが、それ以外のプロセスからは見えません。カーネルバージョン 5.6 以降、8 種の namespace があります(namespaces(7) と unshare(1) と nsenter(1) を参照下さい)。

Debian 11 Bullseye (2021年) の時点では、Debian は統一 cgroup ヒエラルキー (cgroups-v2と呼ばれています)。

プロセスを隔離しリソースコントロールを可能にする cgroups を使う namespaces の使用例は以下です:

このような機能は「普通の Unix 認証」では実現できません。このような高度のトピックスは当該入門書のほぼ対象外です。