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

目次

4.1. 通常の Unix 認証
4.2. アカウントとパスワードの情報管理
4.3. 良好なパスワード
4.4. 暗号化されたパスワード作成
4.5. PAM と NSS
4.5.1. PAM と NSS によってアクセスされる設定ファイル
4.5.2. 最新の集中システム管理
4.5.3. 「どうして GNU の su は wheel グループをサポートしないのか」
4.5.4. パスワード規則強化
4.6. 認証のセキュリティー
4.6.1. インターネット上でセキュアーなパスワード
4.6.2. セキュアーシェル
4.6.3. インターネットのためのセキュリティー強化策
4.6.4. root パスワードのセキュリティー確保
4.7. 他のアクセスコントロール
4.7.1. sudo
4.7.2. PolicyKit
4.7.3. サーバーのサービスへのアクセスの制限
4.7.4. Linux のセキュリティ機能

人 (またはプログラム) がシステムへのアクセスの要求をした際に、認証はその正体が信頼できるものだと確認します。

[警告] 警告

PAM の設定のエラーはあなたをあなた自身のシステムから締め出すかも知れません。レスキュー CD を手元に置くか代替ブートパーティション設定を必ずします。復元するには、それらを使ってシステムをブートしそこから修正します。

通常の Unix 認証は PAM (プラグ可能な認証モジュール) のもとで pam_unix.so(8) モジュールによって提供される。":" で分離されたエントリーを持つその3つの重要な設定ファイルは次です。


"/etc/passwd" ファイルは次の内容です。

 ...
user1:x:1000:1000:User1 Name,,,:/home/user1:/bin/bash
user2:x:1001:1001:User2 Name,,,:/home/user2:/bin/bash
 ...

passwd(5) に説明されているように、このファイルの ":" で分離されたエントリーそれぞれは次の意味です。

  • ログイン名

  • パスワード規定エントリー

  • 数値のユーザー ID

  • 数値のグループ ID

  • ユーザー名またはコメント領域

  • ユーザーのホームディレクトリー

  • ユーザーのコマンドインタープリター (無いこともある)

"/etc/passwd" の2番目のエントリーは暗号化したパスワードのエントリーとして使われていました。"/etc/shadow" が導入された後は、このエントリーはパスワード規定エントリーとして使われています。


"/etc/shadow" の内容は次です。

 ...
user1:$1$Xop0FYH9$IfxyQwBe9b8tiyIkt2P4F/:13262:0:99999:7:::
user2:$1$vXGZLVbS$ElyErNf/agUDsm1DehJMS/:13261:0:99999:7:::
 ...

shadow(5) で説明されているように、このファイルの ":" で分離されたエントリーそれぞれは次の意味です。

  • ログイン名

  • 暗号化されたパスワード (最初が "$1$" で始まっているのは MD5 暗号化が使われていることを示します。"*" はログイン不可を示します。)

  • 1970 年 1 月 1 日から、最後にパスワードが変更された日までの日数

  • パスワードが変更可能となるまでの日数

  • パスワードを変更しなくてはならなくなる日までの日数

  • パスワード有効期限が来る前に、ユーザが警告を受ける日数

  • パスワード有効期限が過ぎてからアカウントが使用不能になるまでの日数

  • 1970 年 1 月 1 日からアカウントが使用不能になる日までの日数

"/etc/group" のファイル内容は次です。

group1:x:20:user1,user2

group(5) に説明されているように、このファイルの ":" で分離されたエントリーそれぞれは次の意味です。

  • グループ名

  • 暗号化されたパスワード (実際は使われていない)

  • 数値のグループ ID

  • "," で分離されたユーザー名のリスト

[注記] 注記

"/etc/gshadow" ファイルは "/etc/shadow" ファイルが "/etc/group" ファイルに対する機能と同様の機能がありますが、実際には使われていません。

[注記] 注記

もし "authoptionalpam_group.so" 行が "/etc/pam.d/common-auth" に書き加えれ、"/etc/security/group.conf" に対応する設定がされていれば、実際のユーザーのグループメンバーシップは動的に割り当てられます。pam_group(8) を参照下さい。

[注記] 注記

base-passwd パッケージはユーザーとグループに関する権威のあるリストが含まれます: "/usr/share/doc/base-passwd/users-and-groups.html"。

アカウント情報管理のための重要コマンドを記します。


一部機能が機能するには root 権限が必要な場合があります。パスワードとデーターの暗号化は crypt(3) を参照下さい。

[注記] 注記

Debian が提供する salsa 機器と同様な PAM と NSS の設定をされたシステム上では、ローカルの "/etc/passwd" や "/etc/group" や "/etc/shadow" の内容がシステムにアクティブに利用されていないことがあります。そういった環境下でも上記コマンドは有効です。

passwd(1) によるとシステムインストール時や passwd(1) コマンドによってアカウント作成する際には、次に記すようなセットからなる少なくとも6から8文字の良好なパスワードを選択するべきです。

  • 小文字のアルファベット

  • 数字の0から9

  • 句読点

[警告] 警告

容易に推測できるパスワードを選んではいけません。アカウント名、社会保険番号、電話番号、住所、誕生日、家族員やペットの名前、辞書にある単語、"12345" や "qwerty" のような単純な文字列…、これらすべてパスワードに選んではいけません。

ソルトを使って暗号化されたパスワードを生成する独立のツールがあります。


Debian システムのような最新の Unix 的システムは PAM (プラグ可能な認証モジュール: Pluggable Authentication Modules)NSS (ネームサービススイッチ: Name Service Switch) メカニズムをローカルのシステム管理者がそのシステム管理用に提供します。それらの役割をまとめると次の様になります。

  • PAM は、アプリケーションソフトウエアーが使う柔軟な認証メカニズムを提供し、パスワードデーターの交換に関与します。

  • NSS は、ls(1)andid(1) 等のプログラムがユーザーやグループの名前を得ために C 標準ライブラリー経由で頻用する柔軟なネームサービスメカニズムを提供します。

これらの PAM と NSS システムは一貫した設定が必要です。

PAM と NSS システムに関する注目のパッケージは次です。


  • libpam-doc 中の "The Linux-PAM System Administrators' Guide" は PAM 設定を学ぶ上で必須です。

  • glibc-doc-reference の中の "System Databases and Name Service Switch" セクションは NSS 設定を学ぶ上で必須です。

[注記] 注記

より大規模かつ最新のリストは "aptitude search 'libpam-|libnss-'" コマンドを実行すると得られます。NSS という頭字語は "ネームサービススイッチ: Name Service Switch" と異なる "ネットワークセキュリティーサービス: Network Security Service" を指すこともあります。

[注記] 注記

PAM は個別プログラムに関する環境変数をシステム全体のデフォールト値に初期化する最も基本的な手段です。

systemd の下では、logind のために systemd のコントロールグループ階層中にユーザーセッションを登録することでユーザーのログインを管理すべくlibpam-systemd パッケージがインストールされている。systemd-logind(8) や logind.conf(5) や pam_systemd(8) を参照ください。

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


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

[ヒント] ヒント

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

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

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

  • スタンドアローンの LDAP デーモンである slapd(8) 等のプログラムを走らせることで集中化された LDAP サーバーを設置します。

  • デフォールトの "pam_unix.so" に代えて "pam_ldap.so" を使うには "/etc/pam.d/" ディレクトリー中の PAM 設定ファイルを変更します。

    • Debian では、"/etc/pam_ldap.conf" をlibpam-ldap の設定ファイル、"/etc/pam_ldap.secret" を root のパスワードを保存するファイルとして使っています。

  • デフォールト ("compat" または "file") に代えて "ldap" を使うには "/etc/nsswitch.conf" ファイル中の NSS 設定を変更します。

    • Debian では、"/etc/libnss-ldap.conf" をlibnss-ldap の設定ファイルとして使っています。

  • パスワードのセキュリティー確保のために libpam-ldapSSL (もしくは TLS) 接続を使うよう設定しなければいけません。

  • LDAP のネットワークオーバーヘッドのコストは掛かりますが、データの整合性確保のために libnss-ldapSSL (もしくは TLS) 接続を使うように設定できます。

  • LDAP のネットワークトラフィックを減少させるために LDAP サーチ結果を一時保持するための nscd(8) をローカルで走らせるべきです。

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

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

[注記] 注記

ここに書かれている情報はあなたのセキュリティーのニーズに充分ではないかもしれませんが、良いスタートです。

多くのトランスポーテーションレイヤーサービスはパスワード認証も含めて暗号化せずにメッセージをプレーンテキストで通信します。途中で傍受されかねないインターネットの荒野を経由して暗号化せずパスワードを送ることは非常によくない考えです。これらに関しては、"トランスポーテーションレイヤーセキュリティー"(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)」を参照下さい。

あなたの機器に他人が 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段目: ブートローダー」参照下さい) なら、次の手順を使えてさらに簡単です。

  1. カーネルパラメーターを "root=/dev/hda6 rw init=/bin/sh" のような感じに変更してシステムを起動します。

  2. "/etc/passwd" を編集し、root アカウントの2番目の項目を空にします。

  3. システム再起動します。

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

[注記] 注記

root シェルにアクセスさえできれば、システム上の全てにアクセスできシステム上のどのパスワードでもリセットできます。さらに。john とか crack パッケージ (「システムのセキュリティーと整合性のチェック」参照下さい) のようなブルートフォースのパスワードクラッキングツールを使ってすべてのユーザーアカウントのパスワードが破られるかもしれません。こうして破られたパスワードは他のシステムへの侵入を引き起こしかねません。

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

There are access controls to the system other than the password based authentication and file permissions.

[注記] 注記

カーネルのセキュアーアテンションキー (SAK) 機能の制限は「Alt-SysRq キー」を参照下さい。

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 インフラ」 を参照下さい。

[ヒント] ヒント

NFS 他の RPC を使うプログラムためには Sun RPC サービスはアクティブにする必要があります。

[ヒント] ヒント

もし現代的な Debian システムでリモートアクセスで問題に会った場合には、"/etc/hosts.deny" 中に "ALL:PARANOID" 等の問題となっている設定があればコメントアウトします。(ただしこの種の行為に関するセキュリティーリスクに注意を払わなければいけません。)

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.