ローカル システムのセキュリティ

はじめに

第42章はじめに

システム管理者の重要なタスクは、内部と外部の両方の脅威からシステムを保護することです。その作業は、適切なセキュリティ ポリシーの設計から始まります。これは、予想される予期しない脅威ベクトルから保護するために作成されます。さらに、適切なシステムのウィルス予防策を実践する必要があります。システムは、タイムリーに保守やアップグレードを行う必要があります。また、侵入者から物理的に保護する必要があります。さらに、優れたポリシーでは、適切なユーザーのみが潜在的な危険性を内包した特権を持つこと、そして持つのは絶対に必要な特権のみであることを保証する必要があります。


学習目標
この章の終わりまでに、次のことができるようになります。

システムのセキュリティ リスクを評価できます。
健全なコンピュータ セキュリティ ポリシーとその手続きを作成し、実装できます。
パスワードでBIOSとブートローダーを効率的に保護できます。
適切なマウントのオプションのsetuidとsetgidを使用して、セキュリティを強化できます。


ローカル システムのセキュリティ

ローカル システム セキュリティの概要
コンピュータは本質的に安全ではなく、侵入したり攻撃したりする人々からの保護が必要です。侵入や攻撃は、システムに害を与える、サービスを拒否する、情報を盗む、ただそれだけのために行われます。

絶対に安全なコンピュータはありません。私たちにできることは、侵入者の動きを鈍化させるか阻止することです。そうすれば、侵入者がもっと簡単に侵入できるターゲットを探しに立ち去るか、または、私たちが侵入の動きを捉えてして適切な処置を取ることができます。

セキュリティとは、システムが本来すべきことを定期的に実行する機能と定義できます。システムの整合性と正確性を実現し、使用を許可された人だけがシステムを使用できるようにすることです。 

セキュリティに関する最大の課題は、セキュリティと生産性の適切な組み合わせを見つけることです。セキュリティの制限が厳しく、解りにくく、使いにくい場合、特に効果のない対策では、ユーザーは使用を避けるでしょう。

保護する必要がある対象は4種類あります。physical（物理的なもの）、 local,（ローカル）、remote（リモート）、personnel（人的なもの）です。このセクションでは、ネットワーク セキュリティではなくローカルのセキュリティを説明します。


セキュリティ ポリシーの作成
重要なことは明確なセキュリティ ポリシーを作成して組織に公開することです。すべきこととして、以下があります。

シンプルで理解しやすくすること
常に更新すること
必要に応じて、オンラインに加えて、書面で文書を示すこと
ポリシーと手続きの両方を説明すること
実施するアクションを指定すること
セキュリティ違反に対して実行するアクションを指定すること。

ポリシーは一般的な表現にし、理解しやすくする必要があります。必要なデータを保護し、要求されたサービスへのアクセスを拒否し、ユーザーのプライバシーを保護する必要があります。

これらのポリシーは定期的に更新する必要があります。要件と同様にポリシーも変更する必要があります。古くなったポリシーを持つことは、ポリシーがないことよりも悪い場合があります。


ポリシーに含めるもの
セキュリティ ポリシーには、権限のない担当者による情報の読み取りやコピーから情報を保護する方法を含める必要があります。また、所有者の許可なく情報が変更または削除されないように保護する必要があります。すべてのサービスを利用できるように保護すべきであり、許可なしにいかなる方法でも傷つけることのないようにする必要があります。

対象にすべき重要なものは以下です。

守秘義務
データの整合性
可用性
一貫性
制御
監査

データが正しいこと、およびシステムが期待どおりに動作することを確認する必要があります。システムへのアクセス権が誰に付与されるかを決定するための、有効なプロセスがあるはずです。人的な要因は、セキュリティ チェーンの中でも最も弱いリンクです。継続的な監査を通じて最も注意を払う必要があります。


評価すべきリスクとは
リスク分析は、次の3つの項目に基づいて行ないます。

何を保護したいか？
何から保護しているか？
適切な保護を提供するには、どれだけの時間、人員、およびお金が必要か？

システムを保護する方法を決定するには、何を何から保護するかを知る必要があります。これにより、システムを保護するためのポリシーとその手続きを計画できます。

これは、コンピュータのセキュリティ ポリシーを構築するための最初のステップです。そして、システムを保護するためのポリシーと手続きを計画・実施するための前提条件です。


セキュリティ方針の選択
ほとんどのコンピューティング環境で使用されている、2つの基本的な方針があります。

明示的に許可されていないものは拒否
明示的に禁止されていないものは許可

自分の組織に最適な方針を決定する必要があります。

方針の最初の選択は、より厳格なものにします。ユーザーは、特権なしの許可を明確かつ明示的に指定されている場合のみ実行できます。これは最も一般的に使用される方針です。

2番目の選択は、ユーザーが明示的に禁止されていること以外は何でも実行できる、より自由な環境を構築します。これは、想定される信頼度が高いことを意味し、明らかな理由で展開される頻度は低くなっています。

各ボックスをクリックして展開し、セキュリティ方針を作る際に覚えておくべき一般的なガイドラインについて学びます。

セキュリティ方針を作るためのガイドライン

人的要因は最も弱いリンクです
ユーザーを教育し、ユーザーを満足させる必要があります。侵入の最大の割合は内部であり、多くの場合悪意のあるものではありません。

不死身のコンピューティング環境はありません
安全な唯一のシステムは、何にも接続されておらず、安全な部屋に閉じ込められて電源がオフになっているシステムです。

被害妄想は良いことです
コンピュータを保護するときは、疑い深く、用心深く、忍耐強く行動してください。保護は、常に注意を払わなければならない継続作業です。プロセスとユーザーを確認し、異常な部分を探します。

ユーザーは絶対に現在のディレクトリをパスに入れないでください。つまり、〜/.bashrcでPATH=/:$ PATHのようなことをしないでください。

これは重大なセキュリティ リスクです。悪意のある人物が同じ名前のプログラムを代用して、有害なことを行う可能性があります。次の行だけを含む、lsという名前のスクリプトを考えてみてください。

/bin/rm -rf $HOME

このファイルが含まれているディレクトリに移動してlsと入力すると、ホーム ディレクトリが消去されてしまします！


システムの更新とパッチ
Linuxディストリビュータ提供の更新とアップグレードに注意を払い、できるだけ早く適用することが重要です。

🚩
全く更新されていないシステムは脆弱であると見なされます。
 

ほとんどの攻撃は、既知のセキュリティホールを悪用し、問題が明らかになってからパッチが適用されるまでの間に行われます。このゼロデイ攻撃は実際には非常に珍しいです。攻撃者は、まだ発見されていないか修正がリリースされていないセキュリティホールを使用します。 

システム管理者は、修正よりも多くの問題を引き起こす、プロプライエタリなオペレーティング システム ベンダーとの苦い経験から、リリース直後に修正を適用することに消極的です。ただし、Linuxでは、このような意味でのセキュリティの低下は非常にまれであり、セキュリティ パッチの適用を遅らせることで生まれる危険性を、おそらく正当化できません。


ハードウェア アクセシビリティの脆弱性
ハードウェアが物理的にアクセス可能なときはいつでも、セキュリティは次の方法で危険にさらされる可能性があります。

キーのロギング：押すキーを含む、コンピュータ ユーザーのリアルタイムのアクティビティを記録します。キャプチャされたデータは、ローカルに保存するか、リモート マシンに送信できます。
ネットワーク スニッフィング：ネットワーク上のネットワーク パケット レベルのデータをキャプチャして表示します。
ライブまたはレスキュー ディスクでの起動。
ディスク コンテンツの再マウントと変更。

システムへの物理アクセスにより、攻撃者は複数の攻撃ベクトルを簡単に利用できるようになります。そうなると、オペレーティング システム レベルの助言はすべて意味のないものになります。

したがって、セキュリティ ポリシーは、サーバーおよびワークステーションへの物理アクセスを適切に保護する方法の要件定義から始める必要があります。


ハードウェア アクセスのガイドライン
必要な保護の手順は次のとおりです。

ワークステーションとサーバーのロック ダウン
信頼できない人によるアクセスからの、ネットワーク リンクの保護
パスワードが入力されているキーボードが改ざんされないように、キーボードを保護
ライブまたはレスキューのCD/DVDやUSBキーでシステムを起動できないように、BIOSをパスワードで保護

シングル ユーザー コンピュータおよび家庭環境のコンピュータの場合は、上記の機能の一部（リムーバブル メディアからの起動の防止など）は過剰反応になる可能性があるため、それらの実装を回避します。ただし、機密情報がシステム上にあるなど慎重に保護する必要がある場合は、そこに置かないようにするか、上記のガイドラインに従って保護を強化する必要があります。


BIOS
BIOSは、システムを構成または操作する最低レベルのソフトウェアです。ブートローダーは、BIOSにアクセスしてマシンを起動する方法を決定します。BIOSとは、

最下位レベルのセキュリティです。
パスワードを使用して保護する必要があります。
更新し、最新状態にする必要があります。

BIOSパスワードを設定すると、権限のない人物がシステムにアクセスするために起動オプションを変更することを防ぐことができます。ただしローカルに存在する必要があるため、問題になるのは誰かがマシンに物理的にアクセスする場合だけです。

また、ファームウェアを最新バージョンにしておくために、BIOSには常にパッチを当てておくことをお勧めします。ただし、ほとんどのBIOSアップデートはセキュリティとは何の関係もありません。また、不十分なBIOSコードだと常に問題が起きるので、不要なアップデートはシステムを役に立たなくする可能性があります。システム管理者は新しいBIOSを適用する際には慎重に行うように指示されています。


ブートローダー
安全なパスワードを使用して起動プロセスを保護し、誰かがユーザー認証手順をすり抜けることを防ぐことができます。これは、BIOSのパスワード保護と連動して機能します。

ブートローダーのパスワードだけを使用した場合、ユーザーがブート プロセス中にブートローダーの設定を編集することはできなくなりますが、ユーザが光ディスクやペン ドライブなどの代替ブート メディアからブートすることを妨ぐことはできません。したがって、完全に保護するには、BIOSパスワードと一緒に使用する必要があります。

古いGRUBバージョン1の場合、GRUBのパスワードを設定するのは比較的簡単でしたが、今主流のGRUBバージョン2の場合は、もっと複雑になっています。ただし、柔軟性が高く、個々のユーザー固有のパスワード（通常のログイン パスワード）の設定を行うことができます。

繰り返しになりますが、grub.cfgを直接編集しないでください。代わりに、/etc/grub.dのシステム構成ファイルを編集してから、update-grubまたはgrub2-mkconfigを実行して、新しい構成ファイルを保存します。

この関連の説明は、UbuntuドキュメントのGrub2/Passwordsウェブ ページにあります。


安全なマウント オプションの使用
ファイルシステムをマウントする場合、mountコマンドを使用してコマンド ラインで、または/etc/fstabに設定して自動的に、さまざまなオプションを指定してセキュリティを強化できます。

nodev
ファイルシステム上のキャラクタやブロックのスペシャル デバイスを利用できないようにします

nosuid
set-user-identifierビットやset-group-identifierビットを無効にします。（setuidとsetgidについては、この後説明します）。

noexec
マウントされたファイルシステム上のバイナリの、直接実行を制限します。

ro
次のように、ファイルシステムを読み取り専用モードでマウントします。
$ mount -o ro,noexec,nodev /dev/sda2 /mymountpt

または/etc/fstabで設定します。
/dev/sda2 /mymountpt ext4 ro,noexec,nodev 0 0


setuid/setgidビット
通常、プログラムは、プログラムを実行しているユーザーの権限で実行されます。これは、実行中のバイナリ実行可能なファイルが実際には誰の所有であっても、プロセスは依然として特権が制限されていることを意味します。

場合によっては、ネットワーク インターフェイスの起動や停止をしたり、スーパーユーザーが所有するファイルを編集したりする機能など、一般のユーザーに通常ではできない拡張機能を持たせることがあります。

実行可能なファイルにsetuid（set user ID）ビットを設定すると、プログラムの実行ユーザーではなく所有者の権限でプログラムを実行することになり、通常の動作を変更できます。

さらに、setgidビットを設定すると、ファイルを実行しているグループの特権ではなく、ファイルを所有しているグループの特権でプロセスは実行されます。

これは一般的に悪い考えであり、ほとんどの状況で行うべきではないことを強調しておきます。多くの場合、この種の設定には、より絞られた特権のデーモン プログラムを作成することが適切です。一部のディストリビューションでは、この設定機能が完全に無効になっています。

デフォルトでは、ファイルがディレクトリに作成されると、そのファイルは、そのファイルを作成したユーザーとユーザーのグループによって所有されます。ディレクトリでsetgid設定を使用すると、ディレクトリで作成されたファイルが、そのディレクトリのグループ所有者によって所有されるように変更されます。これにより、ユーザーのグループがファイルを共有できる、共有ディレクトリを作成できます。

これは以下のコマンドで行います。

$ chmod u+s somefile
$ chmod g+s somefile

最初の例はsetuid操作を実行し、2番目の例はsetgid操作を実行します。

ディレクトリの場合、グループ ビットを設定すると異なる効果があります。次のように、共有ディレクトリを作成するために使用されます。

$ chmod g+s somedir

このディレクトリに作成されたファイルは、ディレクトリのグループ所有者の所有となります。

シェル スクリプト形式のファイルのsetuid設定は、実質的には変更できないことに注意してください。実際、シェルのsetuidビットを変更しなければ何も起こりませんが、もし変更すると、ひどいセキュリティ ホールになります。setuidの変更は、実行可能なバイナリ プログラムでのみ実行できます。


演習

課題 42.1: セキュリティとマウントのオプション

🚩
以下のPDFドキュメントに埋め込まれた外部URLにアクセスする場合は、常に右クリックして新しいタブまたはウィンドウで開いてください。直接クリックしてURLを開こうとすると、コース ウィンドウ／タブが閉じます。

【【これ以降は橋本さん訳を参照】】

We are going to mount a partition or loop device with the noexec option to prevent execution of programs that reside on the filesystem there in.  You can certainly do this with a pre-existing and mounted partition,  but you may not be able to easily change the behavior while the partition is mounted.  Therefore, to demonstrate we’ll use a loop device, which is a harmless procedure.

1.  Set up an empty file, put a filesystem on it and mount it.

2.  Copy an executable file to it from somewhere else on your system and test that it works in the new location.

3.  Unmount it and remount with the noexec option.

4.  Test if the executable still works. It should give you an error because of the noexec mount option.

5.  Clean up.

Solution 42.1

1.$ dd if=/dev/zero of=image bs=1M count=100
$ sudo mkfs.ext3 image
$ mkdir mountpoint
$ sudo mount -o loop image mountpoint

2.$ sudo cp /bin/ls mountpoint
$ mountpoint/ls

3.$ sudo umount mountpoint
$ sudo mount -o noexec,loop image mountpoint
または
$ sudo mount -o noexec,remount image mountpoint

4.$ mountpoint/ls

5.$ sudo umount mountpoint
$ rm image
$ rmdir mountpoint

Note that this is not persistent. To make it persistent you would need to add the option to /etc/fstab with a line like:

in/etc/fstab

/home/student/image  /home/student/mountpoint    ext3    loop,rw,noexec0 0


課題 42.2: setuidとスクリプトについて

🚩
以下のPDFドキュメントに埋め込まれた外部URLにアクセスする場合は、常に右クリックして新しいタブまたはウィンドウで開いてください。直接クリックしてURLを開こうとすると、コース ウィンドウ／タブが閉じます。

Exercise 42.2: More on setuid and Scripts

Suppose we have the following C program (./writeit.c) which attempts to overwrite a file in the current directory named afile. This file can be extracted from your downloaded SOLUTIONS file as writeit.c.

writeit.c

1/*
2@*/
3#include <stdio.h>
4#include <unistd.h>
5#include <fcntl.h>
6#include <stdlib.h>
7#include <string.h>
8#include <stdlib.h>
9#include <sys/stat.h>
10
11int main(intargc,char*argv[])
12{
13intfd, rc;
14char*buffer ="TESTING A WRITE";
15fd = open("./afile", O_RDWR | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
16rc = write(fd, buffer, strlen(buffer));
17printf("wrote %d bytes\n", rc);
18close(fd);
19exit(EXIT_SUCCESS);
20}

If the program is called writeit.c, it can be compiled simply by doing:

$ make writeit

or equivalently

$ gcc -o writeit writeit.c

If (as a normal user) you try to run this program on a file owned by root you’ll get

$ sudo touch afile
$ ./writeit
wrote -1 bytes

but if you run it as root:

$ sudo ./writeit
wrote 15 bytes

Thus, the root user was able to overwrite the file it owned, but a normal user could not.
Note that changing the owner of writeit to root does not help:

$ sudo chown root.root writeit
$ ./writeit
wrote -1 bytes

because it still will not let you clobber afile.
By setting the setuid bit you can make any normal user capable of doing it:

$ sudo chmod +s writeit
$ ./writeit
wrote 15 bytes

Please Note

You may be asking,  why didn’t we just write a script to do such an operation,  rather than to write and compile an executable program?
Under Linux, if you change the setuid bit on such an executable script, it won’t do anything unless you actually change the setuid bit on the shell (such as bash) which would be a big mistake; anything running from then on would have escalated privilege!


知識チェック

「第42章 - ローカル システムのセキュリティ」を完遂しました。おめでとうございます。このクイズに答えて、これまでに学んだ概念の理解度をチェックしてください。

クイズ開始

問題 42.1
ユーザー アカウントにパスワードを使用することは一般的であり、セキュリティとプライバシーの基本的なツールです。ただし、システムのセキュリティを大幅に向上させるために設定できる2つの追加パスワードがあります。USBディスクなどの外部デバイスからオペレーティング システムを読み込まないように設定できる、2つの追加パスワードはどれですか。当てはまるものをすべて選択してください。

A. /ディレクトリをLUKSで暗号化します。
B. LUKSを使用して/bootディレクトリを暗号化します。
C. BIOSパスワードを設定します。
D. ブートローダーのパスワードを設定します。


