Info: Version 1.8.x is available.

English Page

Last modified: $Date: 2024-03-30 20:25:00 +0900 (Sat, 30 Mar 2024) $

TOMOYO Linux の世界
第９回：「ログインセッションを制限してみよう（後編）」

今回の内容

前回は，システムにログインして行う操作を制限する手順のうち，ドメイン遷移とファイルアクセスに関する制限について解説しました．今回は，ネットワーク（通信）の制限と実際の操作手順を説明します．

ステップ３：通信を許可したいネットワークの決定

ネットワークのアクセス制限

システムにログインしたユーザはファイルへのアクセスだけでなくネットワークにもアクセスすることでしょう．そこで，ログインしたユーザに対してどのサーバへのアクセスを許可するかを設計します．ネットワークに関するアクセス許可の構文は，「 allow_network プロトコル ＩＰアドレス ポート番号」となっています．プロトコルは TCP または UDP または RAW のいずれか，ＩＰアドレスはＩＰｖ４またはＩＰｖ６アドレスを指定します．ＩＰアドレスの部分は前回の記事で説明したファイルのグループ化と同様にグループ化が可能です．ここではＨＴＴＰ，ＤＮＳ，ＦＴＰ，ＳＳＨの設定について説明します．

●ＨＴＴＰ

最初に，ＨＴＴＰサーバのＩＰアドレスを HTTP_SERVERS という名前でグループ化することにします．グループ化することにより，ポリシーファイルを読みやすくすることができ，また，サーバのＩＰアドレスの変更や追加や削除が発生した場合にも修正個所が１ヵ所で済みます．ＩＰアドレスをグループ化するには， address_group というキーワードを使います．ＨＴＴＰサーバのアドレスが 192.168.1.100 と 192.168.1.200 の場合，例外ポリシーで図１のように定義してから，ログインシェルのドメイン（ <kernel> /usr/sbin/sshd /bin/bash ）に対して図２という許可を与えます（以降に登場する DNS_SERVERS や FTP_SERVERS や SSH_SERVERS も， HTTP_SERVERS と同様に定義してください）．

address_group HTTP_SERVERS 192.168.1.100
address_group HTTP_SERVERS 192.168.1.20

allow_network TCP connect @HTTP_SERVERS 80

●ＤＮＳ

ＤＮＳサーバとの通信ではＵＤＰプロトコルのポート 53 を使うので，ログインシェルのドメインに対して図３という許可を与えます．

allow_network UDP connect @DNS_SERVERS 53

●ＦＴＰ

ＦＴＰサーバとの通信ではＴＣＰプロトコルのポート 21 を使うので，図４という許可を与えます．

allow_network TCP connect @FTP_SERVERS 21

ＦＴＰプロトコルではサーバ側からクライアント側へ向けてＴＣＰコネクションを張る場合があるので，図５の許可が必要になる場合があります．

allow_network TCP accept @FTP_SERVERS 20

ファイアウォールの内側にいる場合など，サーバ側からクライアント側へ向けてＴＣＰコネクションを張ることができない場合にはパッシブモードを使うので，図５の代わりに図６という許可を与えることになるでしょう．

allow_network TCP connect @FTP_SERVERS 1024-65535

●ＳＳＨ

ＳＳＨサーバとの通信ではＴＣＰプロトコルでポート 22 へコネクションを張るので，図７という許可を与えることになります．

allow_network TCP connect @SSH_SERVERS 1024-65535

ただし，前回のドメイン遷移の設計では，ＳＳＨの秘密鍵へのアクセスを認める必要がある /usr/bin/ssh コマンドはログインシェルとは別のドメインで動作させるように指定している（図８）ので，このアクセス許可はログインシェルのドメインにではなく， /usr/bin/ssh のドメイン（図９）に対して与えることに注意してください．ポリシーエディタを実行して，「 A 」を押してからリスト９の内容を入力して「 Enter 」を押すことで /usr/bin/ssh のドメインを作成できます．

no_keep_domain /usr/bin/ssh from <kernel> /usr/bin/sshd /bin/bash

<kernel> /usr/sbin/sshd /bin/bash /usr/bin/ssh

ステップ４：学習の開始

さて，これまでの作業でアクセス許可の基本的な設定が完了しました．しかし，これだけではまだアクセス許可が不足していますから，学習モードを用いて不足しているアクセス許可を追加していくことにします．ポリシーエディタを用いてログインシェルのドメインとその子孫ドメインに対してプロファイル１を割り当てます（ポリシーエディタを使わずに， root ユーザで図１０のコマンドラインを実行しても結構です）．

# /usr/sbin/ccs-setprofile -r 1 '<kernel> /usr/sbin/sshd /bin/bash'

そして，許可したい操作（具体的には，前回定義した COMMANDS_FOR_LOGIN_SESSION に含まれているコマンドを実行したり， HOME_FILE に該当するファイルを編集したり，ネットワークへアクセスしたりなど）を行ってください．操作例として，図１１～図１５の内容を参考にしてください．

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/example/.ssh/id_rsa):
Created directory '/home/example/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/example/.ssh/id_rsa.
Your public key has been saved in /home/example/.ssh/id_rsa.pub.
The key fingerprint is:
c7:4f:53:39:6f:7e:17:fb:ec:94:0d:02:09:84:d5:67 example@tomoyo

$ ssh 192.168.99.138 id
example@192.168.99.138's password:
uid=500(example) gid=500(example) groups=500(example)

$ passwd
Changing password for user example.
Changing password for example
(current) UNIX password:
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.

$ wget http://192.168.1.100/
Length: unspecified [text/html]
Saving to: `index.html'
[ <=>     ] 2,997       --.-K/s   in 0s
14:22:14 (286 MB/s) - `index.html' saved [2997]

$ ls .bashrc | xargs /bin/cat > /dev/null

ここでは，一般ユーザとして example ユーザを使用しています．前回の手順で図１６のようにホームディレクトリ以下のファイルの読み書きに関するアクセス許可をあらかじめ与えているため，図１６に含まれるアクセス要求は学習されません．

allow_execute @COMMANDS_FOR_LOGIN
allow_read/write @HOME_FILE if task.uid=path1.uid
allow_create @HOME_FILE 00-0666 if task.uid=path1.parent.uid
allow_unlink @HOME_FILE if task.uid=path1.uid
allow_symlink @HOME_FILE if task.uid=path1.parent.uid
allow_link @HOME_FILE @HOME_FILE if task.uid=path1.uid task.uid=path1.parent.uid task.uid=path2.parent.uid
allow_rename @HOME_FILE @HOME_FILE if task.uid=path1.uid task.uid=path1.parent.uid task.uid=path2.parent.uid
allow_truncate @HOME_FILE if task.uid=path1.uid
allow_rewrite @HOME_FILE if task.uid=path1.uid
allow_mkdir @HOME_DIR 00-0777 if task.uid=path1.parent.uid
allow_rmdir @HOME_DIR if task.uid=path1.uid
allow_rename @HOME_DIR @HOME_DIR if task.uid=path1.uid task.uid=path1.parent.uid task.uid=path2.parent.uid

ただし，図１７に示したようにＳＳＨの秘密鍵を保存するディレクトリは HOME_FILE から除外してあるので，図１１の操作を行うと /home/example/.ssh/id_rsa のように個別に学習されます．

path_group HOME_FILE /home/\{\*\-.ssh\}/\*
path_group HOME_DIR /home/\{\*\-.ssh\}/

ポリシーのチューニング

確認モードに切り替える

ポリシーエディタを用いてログインシェルのドメインとその子孫ドメインに対してプロファイル２を割り当てます．ここから先は必要に応じて学習モード（プロファイル１）と確認モード（プロファイル２）を切り替えながら使います．ポリシーエディタを起動して，ログインシェルのドメインに対して与えられたアクセス許可の内容を確認してください．実は，前回の連載の手順では解説を行うために意図的にいくつかの設定を不完全なものにしています．この後，順に内容を見ながら修正していきますので，読みながら一緒に考えてみてください．

ドメイン遷移の見直し

前回， /usr/bin/ssh をログインシェルとは別のドメインで実行するように指定しました．しかし，よくよく考えてみると，ＳＳＨの秘密鍵へのアクセスを認めなければいけないのは /usr/bin/ssh-keygen も同じです．せっかく /usr/bin/ssh をログインシェルとは別のドメインで動作させることで /bin/cat などでアクセスできないようにしようとしているのに， /usr/bin/ssh-keygen がログインシェルのドメインで動作してしまうと，ログインシェルのドメインからもＳＳＨの秘密鍵へアクセスできるようになってしまいます．そこで， /usr/bin/ssh-keygen も /usr/bin/ssh と同様にログインシェルとは別のドメインで実行させるように修正します．単純に図１８の指定を追加するだけでも可能ですが，「ＳＳＨの秘密鍵へのアクセスを認めなければいけないプログラム」という意味で /usr/bin/ssh と /usr/bin/ssh-keygen を同じようにまとめて扱うという考え方もあります．

no_keep_domain /usr/bin/ssh-keygen from <kernel> /usr/sbin/sshd /bin/bash

そのような目的のために TOMOYO Linux では， aggregator というキーワードが利用できます．構文は「 aggregator 集約前のプログラム名 集約後のプログラム名」で，このように指定すると「集約前のプログラム」は「集約後のプログラム名」と同様に扱われます．図１９のように指定すると， /usr/bin/ssh-keygen の実行が要求された場合，実行許可のチェックとドメイン遷移処理は /usr/bin/ssh の実行が要求されたものとして行われるようになります．

aggregator /usr/bin/ssh-keygen /usr/bin/ssh

そのため，図２０のようなドメインを作成したり，図１８という指定を追加したりする必要がなくなります．

<kernel> /usr/sbin/sshd /bin/bash /usr/bin/ssh-keygen

今回は aggregator を使うことにしますので，図１９の内容を例外ポリシーに追加してください．その後，ログインシェルのドメインからＳＳＨ関連ファイルへのアクセス許可を削除しておいてください．

path_group の更新

ログインシェルのドメインに与えられたプログラムの実行許可を見ると，図２１の内容も学習されていることがわかります．これは前回，実行を許可するコマンドを定義したときに想定していなかったものです． /usr/bin/xargs は複数のファイルに対して一括操作を行うときに便利なコマンドですので，ログインセッションでの実行を許可することにします．このまま図２１の内容を残しておいてもかまいませんが， xargs コマンドは argv[0] をチェックしなくても問題にならないので COMMANDS_FOR_LOGIN_SESSION グループに追加してみましょう．

allow_execute /usr/bin/xargs

例外ポリシーの画面に移動して，図２２のエントリを追加してから，ログインシェルのドメインに戻って図２１の内容を削除します．

path_group COMMANDS_FOR_LOGIN_SESSION /usr/bin/xargs

ケイパビリティについて

学習モードで操作を行うと，図２３のように allow_capability で始まる行が学習されたと思います．ケイパビリティは許可する操作種別を指定するだけであるため，操作対象を指定する必要はありません．学習モードで必要だったものは運用中にも必要になるのでそのまま残しておきます．

allow_capability SYS_CHMOD
allow_capability SYS_IOCTL
allow_capability SYS_KILL
allow_capability SYS_LINK
allow_capability SYS_RENAME
allow_capability SYS_SYMLINK
allow_capability SYS_UNLINK

なお， TOMOYO Linux で扱うケイパビリティは，普通の Linux が扱うＰＯＳＩＸケイパビリティとは異なり，独自に定義したものですのでご注意ください．

シグナルについて

学習モードで操作中に， allow_signal で始まる行が学習されたかもしれません． TOMOYO Linux ではシグナルの送信先を制限することもできます．シグナルを送信する場合には /bin/kill というコマンドを使用します．しかし， /bin/bash などのシェルは，内部コマンドとして kill というコマンドを提供しているため，実際には /bin/bash から /bin/kill を実行することなくシグナルを送信することができます．そのため，シグナルの送信を制限しない場合， COMMANDS_FOR_LOGIN_SESSION に /bin/kill が含まれていないにもかかわらず， root ユーザとしてログインして /bin/bash の内部コマンドとしての kill コマンドを使用することで任意のプロセスを強制終了させてしまうことができてしまいます．シグナルのアクセス制御を行うにはプロファイル中で CONFIG::ipc::signal を有効にします．今回使用しているプロファイルでは有効になっているので，シグナルの送信要求を制限することができます．シグナルに関するアクセス許可の構文は，「 allow_signal シグナル番号 送信先ドメイン名」となっています．シグナルの送信先となるプロセスが属しているドメインのドメイン名が「送信先ドメイン名」で始まる場合に，「シグナル番号」の種類のシグナルを送信できます（いくつか例外がありますが，通常は気にする必要はありません．詳細についてはプロジェクトのＷｅｂページのポリシー仕様書を参照ください）．

仕上げ

学習モードと確認モードを繰り返す

再度学習モードで学習を行い，確認モードで許可したい操作を行ってください．警告メッセージが表示されないようになれば学習は完了です．確認モードでポリシーエディタを実行し，ログインシェルのドメインに対して不適切なアクセス許可（たとえば /etc/shadow へのアクセス許可やＳＳＨ秘密鍵へのアクセス許可など）がないことを確認してください．

強制モードに切り替える

ポリシーエディタを用いてログインシェルのドメインとその子孫ドメインに対してプロファイル３を割り当てます．ポリシーエディタなどを用いてポリシーを変更できるのは（設定により一般ユーザによる変更を認めるようにもできますが，デフォルトでは） root ユーザだけです． root ユーザの操作を制限するつもりがないのならこのままでもかまいませんが， root ユーザで行う作業の一部を委託する場合，ＳＳＨログインしたログインシェルからポリシーエディタを用いてアクセス制御を無効化されてしまっては困ります．そのため，自分以外に root ユーザとしてＳＳＨログインさせる場合には，ログインシェルのドメイン（ <kernel> /usr/sbin/sshd /bin/bash ）からポリシーエディタ（ ccs-editpolicy や ccs-setprofile など）の実行許可および /proc/ccs/\* へのアクセス許可を削除しておくのを忘れないでください．

以上で TOMOYO Linux を用いてログインセッションを制限する方法の説明は終わりです．

次回予告

次回は Apache の権限をより詳細に分割する方法について紹介します．

第８回へ戻る　第１０回へ進む

目次へ戻る