第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. アクセス制御リスト (ACLs)
4.7.2. sudo
4.7.3. PolicyKit
4.7.4. サーバーのサービスへのアクセスの制限
4.7.5. 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" パーティション) を使うことです。でも、パスワードがシステムのブート毎に必要になってしまいます。

パスワードによる認証システムやファイルパーミッション以外のシステムへのアクセスコントロールがあります。

[注記] 注記

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

ACL は、「ファイルシステムのパーミッション」 で説明された通常のパーミッションの上位集合です。

現代的なデスクトップ環境では ACL が作動していることに出くわします。フォーマットされた USB ストレージデバイスが例えば "/media/penguin/USBSTICK" として自動マウントされた場合、通常ユーザーの penguin は以下を実行できます:

 $ cd /media/penguin
 $ ls -la
total 16
drwxr-x---+ 1 root    root    16 Jan 17 22:55 .
drwxr-xr-x  1 root    root    28 Sep 17 19:03 ..
drwxr-xr-x  1 penguin penguin 18 Jan  6 07:05 USBSTICK

11 列目にある "+" は ACL 作動を表示しています。ACL 無しだと、通常ユーザーの penguin は、penguinroot グループに属さないためこのようにリストできません。ACL は以下のようにして確認できます:

 $ getfacl .
# file: .
# owner: root
# group: root
user::rwx
user:penguin:r-x
group::---
mask::r-x
other::---

ここで:

  • "user::rwx" や "group::---" や "other::---" は、通常の所有者や、グループや、第三者のパーミッションに対応します。

  • "user:penguin:r-x" という ACL は通常ユーザーの penguin が "r-x" パーミッションを保有することを可能にします。 これにより、"ls -la" でディレクトリー内容をリストできるようになります。

  • "mask::r-x" という ACL はパーミッションの上限を設定します。

詳細は "POSIX Access Control Lists on Linux" や acl(5) や getfacl(1) や setfacl(1) を参照下さい。

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

[ヒント] ヒント

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

[ヒント] ヒント

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

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 認証」では実現できません。このような高度のトピックスは当該入門書のほぼ対象外です。