Info: Version 1.8.x is available.
Last modified: $Date: 2024-03-30 11:25:00 +0000 (Sat, 30 Mar 2024) $
今回はシステムにログイン後行う操作を制限する方法について解説します．
SELinux では現在 reference policy への移行が進行中ですが，これまではログインセッションを含めてすべてのプロセスに対して強制アクセス制御を適用する strict ポリシーと，攻撃を受けやすいサービスに対してだけ強制アクセス制御を適用する targeted ポリシーの２種類がデフォルトポリシーとして提供されていました．「セキュリティの強化」という観点からは，文字通り厳格な strict ポリシーのほうが効果が高いわけですが，制限の内容を間違えるとログインすらできなくなるなどの問題もあり， SELinux を有効にしているユーザの多くは targeted ポリシーをベースにカスタマイズしているケースが多いのではないかと思われます． Russell Coker 氏やＬＫＭＬでの SELinux 関係者の発言によると， SELinux 陣営には，「 SELinux のポリシーの内容を理解できないシステム管理者はポリシーを修正すべきではない．我々プロが作成したポリシーをそのまま使いなさい」という考え方があります．これに対して，「システム管理者自身がポリシーを作成する」 TOMOYO Linux は，まっこうから考え方が異なっています．これに関連した議論の一部は， https://slashdot.jp/linux/article.pl?sid=07/06/07/1211201 から辿ることができます．読者のみなさんはどのように考えられますでしょうか．
さて，この連載は TOMOYO Linux の連載なので，ポリシーを自分で作ることができる TOMOYO Linux を使って，ログインして行う操作の制限を行ってみることにしましょう．
Linux をサーバとして利用する場合，ユーザがシステムにログインしてからの操作を制限したいと思う場合があるでしょう．たとえば， 「システム管理者が顧客情報の格納されたデータベースファイルを持ち出すのを禁止したい」とか「システムにログインしたユーザに対してパスワードの変更だけを許可したい」とか「Ｗｅｂサーバの再起動とＷｅｂコンテンツの更新だけを社外に委託したい（それ以外の操作は行えないようにしたい） 」などなど．他にも， 「システムにログインしたユーザが他人のパスワードを盗聴するためのバックドアを仕掛けるのを阻止したい」とか「インターネットから社内ネットワークにアクセスするためのゲートウェイサーバとして使いたい」という要求もあるかもしれません．プロセスの起動履歴ごとにドメインを管理する TOMOYO Linux を使えば，このような要求に対応するのは簡単です．
ログインセッションを保護するための手順は大きく分けて４つあります．
以上の手順で登場するキーワードを図１に示します．
■図１ 使用するキーワード
|
システムにログインしたユーザが悪意あるプログラムを実行できないようにするには，あらかじめシステムにインストールされているプログラム以外の実行を禁止するのが効果的です．この連載では，システムにすでにインストールされているプログラムの内，ログインセッションにおいて図２のコマンドの実行だけを許可するものとします．
■図２ 実行を許可するコマンド
|
これらのコマンドを path_group として例外ポリシーに登録しておきましょう（図３）．ただし，図２の中に起動時の名前（ argv[0] ）によって異なる動作をするようなプログラムがある場合には，そのプログラムは path_group から除外し， allow_execute /usr/bin/passwd if exec.argv[0]="passwd" のように個別に指定するようにしてください．
■図３ 実行を許可するコマンドをグループ化
path_group COMMANDS_FOR_LOGIN_SESSION /bin/basename path_group COMMANDS_FOR_LOGIN_SESSION /bin/bash （中略） path_group COMMANDS_FOR_LOGIN_SESSION /usr/bin/wget path_group COMMANDS_FOR_LOGIN_SESSION /usr/bin/which |
コマンドの所在（パス）を確認するには which や type などのコマンドを使います（図４）．
■図４ コマンドの所在を確認する
# which perl sed grep /usr/bin/perl /bin/sed /bin/grep |
「 /sbin/consoletype や /usr/bin/dircolors なども許可する必要があるの？」と思われるかも知れませんが，シェルを起動したときに自動実行されるスクリプト（ /bin/bash の場合は ~/.bashrc ）によって利用者が意識していない場所で多くのコマンドが実行されています．それらの内容を知るためには， TOMOYO Linux カーネルで動作しているシステムで「ログイン」してすぐに「ログアウト」してください．そうすることで，ログインシェルの子ドメインという形でどのようなコマンドが実行されたのかを知ることができます．さらに， CONFIG::file={ mode=learning } （学習モード）が指定されたプロファイルをログインシェルのドメインに割り当てた状態で実行すれば，プログラムの実行だけでなくアクセスされたファイルも知ることができます．
これまでの連載で説明してきたように TOMOYO Linux では，原則としてコマンドを実行するたびにドメイン遷移を行う仕様となっています．そのため，たとえば図５の場合は /bin/cat はシェルの子ドメインとして動作しますが，図６の場合は /bin/cat は /usr/bin/xargs の子ドメインとして動作します．
■図５ シェルから /bin/cat を実行
# /bin/cat /etc/*.conf |
■図６ xargs から /bin/cat を実行
# echo /etc/*.conf | xargs /bin/cat -- |
しかし，この場合はどちらも同じドメインで動作してくれたほうがユーザとしては使い勝手が良く，まとめたとしてもとくにセキュリティ上の問題はなさそうですね．ログインセッションでは，どのようなコマンドをどのような順序で実行するかを予測することが困難であるため，原則としてドメイン遷移は行いません．ログインシェルを /bin/bash と仮定した場合， /usr/sbin/sshd からログインしたシェルのドメインは <kernel> /usr/sbin/sshd /bin/bash となるので，例外ポリシーに「 keep_domain <kernel> /usr/sbin/sshd /bin/bash 」という指定を行うことでドメイン遷移を抑制します．しかし，パスワードを格納している /etc/shadow のように， /bin/cat コマンドなどで閲覧されるのは困るが，パスワードを変更する /usr/bin/passwd コマンドがアクセスできないのも困るという場合があります．そのような場合は，例外ポリシーに「 no_keep_domain /usr/bin/passwd from <kernel> /usr/sbin/sshd /bin/bash 」という指定を行うことで， /usr/bin/passwd コマンドを <kernel> /usr/sbin/sshd /bin/bash /usr/bin/passwd ドメインで実行させることができます．同様に，ＳＳＨの秘密鍵などを格納している ~/.ssh/ ディレクトリのファイルのように， /bin/cat コマンドなどで閲覧されては困るが，ＳＳＨ接続を行う /usr/bin/ssh コマンドがアクセスできないのも困るので，例外ポリシーに「 no_keep_domain /usr/bin/ssh from <kernel> /usr/sbin/sshd /bin/bash 」という指定を行うことで， /usr/bin/ssh コマンドを別のドメインで実行させることができます．
TOMOYO Linux ではハードリンクの作成時には「リンク元のパス名／リンク先のパス名」をペアにして，名前の変更時には「変更前のパス名／変更後のパス名」をペアにしてアクセス許可のチェックを行っています．その理由について触れておきます．システム（ TOMOYO Linux カーネルで動作しているシステムである必要はありません）にログインして，図７の操作を試してみてください（ /etc/ ディレクトリと /tmp/ ディレクトリが別のパーティションになっているシステムでは失敗します．その場合， /etc/ ディレクトリと同じパーティションにある /root/ ディレクトリなどに読み替えてください）．
■図７ ハードリンク経由でパスワードファイルにアクセスする
# ln /etc/shadow /tmp/shadow # cat /tmp/shadow |
これは，ログインパスワードを格納している /etc/shadow というファイルを /tmp/ ディレクトリの下にハードリンクすることで， /tmp/shadow というパス名を用いてログインパスワードを格納しているファイルにアクセスできることを示しています．「 /etc/shadow を /tmp/shadow にハードリンクしてしまうシステム管理者なんていないよ」と思われるかもしれませんが，実は， /etc/shadow のハードリンクの作成は root ユーザでなくても可能です．一般ユーザが /etc/shadow のハードリンクを一般ユーザが書き込めるディレクトリである /tmp/ ディレクトリに作成し，実行を許可されているコマンド（たとえば /usr/bin/sudo ）を利用して root 権限を手に入れてから， /tmp/ ディレクトリにハードリンクされたパスワードファイルにアクセスできてしまう危険性があるのです．だから TOMOYO Linux では，ハードリンクを作成する際に，リンク元とリンク先の両方をチェックすることでその危険性を最小限に抑えられるようにしているわけです．（実際に /tmp/shadow を作成した方は，この先を読み続ける前に，忘れないうちに /tmp/shadow を削除しておくように！） /etc/shadow のリンク数が２以上であれば，どこかにハードリンクが残っています（図８）．
■図８ /etc/shadow のハードリンクを削除する
# ls -l /etc/shadow -r-------- 2 root root 946 May 29 18:14 /etc/shadow # unlink /tmp/shadow # ls -l /etc/shadow -r-------- 1 root root 946 May 29 18:14 /etc/shadow |
名前の変更についても同様です． /etc/shadow の読み書きは厳しく制限できますが， /tmp/ ディレクトリ内のファイルの読み書きを厳しく制限することは困難です．しかし，図９のような操作ができてしまうようでは困ります（ /etc/ ディレクトリと /tmp/ ディレクトリが別のパーティションになっているシステムでは，パーティションを跨ぐ名前の変更はできないので， /etc/shadow の読み書きを禁止することで /tmp/ ディレクトリに移動されることを防止できます）．
■図９ 名前を変更してからパスワードファイルにアクセスする
# mv /etc/shadow /tmp/shadow # cat /tmp/shadow # mv /tmp/shadow /etc/shadow |
そのため， TOMOYO Linux ではファイル名を変更する際に，変更前のパス名と変更後のパス名の両方をチェックすることで，その危険性を最小限に抑えられるようにしています．パス名でアクセスを制限する方式では，ちょっとした油断で想定外のアクセスを認めてしまうことになります． TOMOYO Linux を用いてハードリンクや名前の変更の許可を与える際には，必要以上の範囲にアクセスさせないように注意してください．
ドメインを遷移させるのは，アクセス権限を切り替えるためです．ログインセッションでは原則としてドメイン遷移を行わないということは，ログインセッションで読み書きを許可するファイルを区別しないことを意味します．基本的に，ログインセッションでは，プログラムファイルを作成したり書き換えたりする必要はありません．そのため，ホームディレクトリ以下のファイルの読み書きを中心に許可すれば良いでしょう．ホームディレクトリ以下のファイルをグループ化するために，例外ポリシーで図１０のグループを定義します．
■図１０ ホームディレクトリのファイルをグループ化
path_group HOME_FILE /home/\{\*\}/\*
path_group HOME_DIR /home/\{\*\}/\*/
|
このように定義すると，ホームディレクトリ以下のファイルを区別しないで扱うことになります．
しかし，ホームディレクトリ以下のファイルでも， ~/.ssh/ ディレクトリのファイルのように， /bin/cat などでの閲覧を禁止させたいファイルがあるはずです．そこで， \*\-.ssh という指定を行うことで， .ssh ディレクトリ内のパス名を除外することができるようになっています．具体的には，図１１のように修正します．
■図１１ .ssh ディレクトリをグループから除外する
path_group HOME_FILE /home/\{\*\-.ssh\}/\*
path_group HOME_DIR /home/\{\*\-.ssh\}/
|
これで， /bin/cat コマンドなどで /home/\*/.ssh/\* にアクセスしたり， /bin/mv コマンドなどで /home/\*/.ssh/ を /home/\*/ssh/ にリネームしたりするのを阻止することができます．
ログインセッションである <kernel> /usr/sbin/sshd /bin/bash ドメインに対しては，図１２のようなアクセスを認めます．
■図１２ あらかじめアクセス許可を与えておく
allow_execute @COMMANDS_FOR_LOGIN allow_read/write @HOME_FILE allow_create @HOME_FILE 00-0666 allow_unlink @HOME_FILE allow_symlink @HOME_FILE allow_link @HOME_FILE @HOME_FILE allow_rename @HOME_FILE @HOME_FILE allow_truncate @HOME_FILE allow_rewrite @HOME_FILE allow_mkdir @HOME_DIR 00-0777 allow_rmdir @HOME_DIR allow_rename @HOME_DIR @HOME_DIR |
上から順番に，
という意味です．なお，図１１の修正により，上記のホームディレクトリには ~/.ssh/ および ~/.ssh/\* に一致するものは含まれません．上記では，ホームディレクトリ内では自由にシンボリックリンクを作成できるようにしています． TOMOYO Linux はシンボリックリンクを解決したパス名を用いてファイルの読み書きを制限しているので，どのようにシンボリックリンクを作成しようとも関係ありません．プログラムの実行時にはシンボリックリンクを経由することで argv[0] の内容を自由に指定できてしまいますが， exec.argv[0] のチェックを有効にしているので， busybox のハードリンクへのシンボリックリンクを作成して任意のコマンドを実行されるという危険性はありません．ホームディレクトリ内でのみハードリンクの作成を認めています．そのため， /etc/shadow のハードリンクをホームディレクトリ内に作成して，ホームディレクトリを経由してパスワードファイルにアクセスされるという危険性はありません．名前の変更についても同様です．
他人が自分のホームディレクトリ内にアクセスしてくるのを阻止するには，ホームディレクトリのパーミッションを 0700 に設定することで実現できます．しかし，たとえば Apache に対して ~/public_html/ ディレクトリへのアクセスを認めるためにホームディレクトリのパーミッションを緩くしておかざるを得ない場合もあります．そんな場合，個々のアクセス許可に対して if task.uid=path1.uid のように条件を付与することで，ホームディレクトリのパーミッションでは防げないアクセスを防げるようになります．具体的には，図１２を図１３のように置き換えます．
■図１３ 所有者によるアクセスのみを認める
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 |
task.uid はアクセスを要求しているプロセスのユーザＩＤ（つまり，ログインしているユーザのユーザＩＤ）， path1.uid は１つ目のパス名（たとえば「 allow_read/write /dev/null 」であれば /dev/null ， allow_link /tmp/source /tmp/dest であれば /tmp/source ）の所有者ＩＤです． path1.parent.uid は path1 の親ディレクトリ（たとえば「 allow_read/write /dev/null 」であれば /dev/ ）の所有者ＩＤです． path2.uid は２つめのパス名（たとえば「 allow_mount /dev/sda2 /home/ ext3 0 」であれば /home/ ）の所有者ＩＤです．ただし， allow_rename や allow_link で指定する２つめのパス名は，アクセス許可のチェックの時点ではアクセスできないパス名であるため， path2.uid という指定はできません． path2.parent.uid は２つ目のパス名（たとえば「 allow_link /tmp/source /tmp/dest 」であれば /tmp/dest ）の親ディレクトリの所有者ＩＤです．
今回は，システムにログインして行う操作を制限する手順のうち，ファイルアクセスに関する部分について解説しました．次回は，残りのステップと実際の操作手順を説明します．