第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)」を参照下さい。

Even when you run secure services such as Secure Shell (SSH) and Point-to-point tunneling protocol (PPTP) servers, there are still chances for the break-ins using brute force password guessing attack etc. from the Internet. Use of the firewall policy (see 「Netfilter インフラ」) together with the following security tools may improve the security situation.

あなたの機器に他人が 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 を使ったアクセスコントロールを使っています。サーバーサービスへのアクセスを制限するには多くの方法があります。

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

Linux kernel has evolved and supports security features not found in traditional UNIX implementations.

Linux supports extended attributes which extend the traditional UNIX attributes (see xattr(7)).

Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities(7), which can be independently enabled and disabled. Capabilities are a per-thread attribute since kernel version 2.2.

The Linux Security Module (LSM) framework provides a mechanism for various security checks to be hooked by new kernel extensions. For example:

Since these extensions may tighten privilege model tighter than the ordinary Unix-like security model policies, even the root power may be restricted. You are advised to read the Linux Security Module (LSM) framework document at kernel.org.

Linux namespaces wrap a global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance of the global resource. Changes to the global resource are visible to other processes that are members of the namespace, but are invisible to other processes. Since kernel version 5.6, there are 8 kinds of namespaces (see namespaces(7), unshare(1), nsenter(1)).

As of Debian 11 Bullseye (2021), Debian uses unified cgroup hierarchy (a.k.a. cgroups-v2).

Usage examples of namespaces with cgroups to isolate their processes and to allow resource control are:

These functionalities can't be realized by 「通常の Unix 認証」. These advanced topics are mostly out-of-scope for this introductory document.