2006年03月30日

ccs-auditd が取得するログについて

ccs-auditd が取得するログは、そのままドメイン用ポリシーとして追加できる形式になっています。

ccs-auditd はログを追記するだけで、ログのローテーションは行いません。 必要に応じて、以下のような内容のファイルを /etc/logrotate.d/tomoyo という名前で作成してください。
(この例は /var/log/tomoyo/ ディレクトリに reject_log.txt という名前で保存している場合です。 /var/log/tomoyo/* と指定してしまうと既にローテーションされたファイルも再度ローテーションされてしまうので注意してください。)

/var/log/tomoyo/*.txt {
  weekly
  rotate 9
  missingok
  notifempty
  nocreate
}

あるいは、定期的にログインして mv コマンドでファイル名を変更するようにしてください。

posted by 熊猫さくら at 20:04| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月29日

udev の扱いについて

/dev/ ディレクトリのデバイスファイルを管理する udev は、 /dev/ ディレクトリに udev のためのディレクトリを作成します。ただし、使われるディレクトリ名はバージョンによって異なっているようです。

もし、 /dev/.udevdb/ ディレクトリが存在している場合、以下のようなパターンを指定してください。

file_pattern /dev/.udevdb/\*

もし、 /dev/.udev/ ディレクトリが存在している場合、以下のようなパターンを指定してください。

file_pattern /dev/.udev/\*
file_pattern /dev/.udev/\*/
file_pattern /dev/.udev/\*/\*
file_pattern /dev/.udev/\*/\*/
file_pattern /dev/.udev/\*/\*/\*
file_pattern /dev/.udev/\*/\*/\*/
file_pattern /dev/.udev/\*/\*/\*/\*
file_pattern /dev/.udev/\*/\*/\*/\*/
file_pattern /dev/.udev/\*/\*/\*/\*/\*
posted by 熊猫さくら at 17:16| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月28日

今後の機能拡張について

カーネル 2.6.16 が公開されたのでそろそろ TOMOYO Linux パッチもバージョンアップしようと思います。

バージョンアップ後、次のような機能拡張ができないかとぼんやりと考えています。

現時点では、 file_pattern として以下のような指定をすることができます。

file_pattern /proc/\$/environ
file_pattern /proc/\$/status
file_pattern /proc/\$/cmdline
file_pattern /proc/\$/stat
file_pattern /proc/\$/statm
file_pattern /proc/\$/cpu
file_pattern /proc/\$/maps
file_pattern /proc/\$/mem
file_pattern /proc/\$/mounts

しかし、 file_pattern だと、指定した階層までしかパターン化できませんし、その階層に作られるファイル名を全て把握していなければいけません。そのため、 /proc/\$/ の部分だけをパターン化するという場合に

dir_pattern /proc/\$/

のような指定ができると便利かなぁと考えています。

実現できるかどうかはまだ判りません。完全一致の file_pattern はパス名を書き直す必要が無いので簡単なのですが、部分一致の dir_pattern はパス名を書き直す必要があるためメモリの割り当て・解放処理という面倒な問題が発生してしまいます。

posted by 熊猫さくら at 17:55| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月27日

/proc/self/ ディレクトリの特例について

Linux では、自プロセスに関する情報は「/proc/self/」ディレクトリから取得できるようになっています。そして、 /proc/self は実際には「自プロセスのプロセスIDの名前が付けられたディレクトリ」へのシンボリックリンクとして実現されています。そのため、自プロセスに関する情報は実際には「/proc/自プロセスのプロセスID/」ディレクトリから取得されます。

version 1.0.2 までは /proc/self/mounts 等の自プロセスの情報を参照するためのアクセス許可は、 /proc/self/mounts ではなく、 /proc/プロセスID/mounts (実際にはパターン化を行って /proc/\*/mounts)というパス名で与えていました。しかし、この方法でアクセスを許可すると、自プロセス以外に対する参照も認めてしまうことになります。カーネル 2.6 では /proc/self/ ディレクトリのファイルに対する書き込みを行う場合が発生しているようですので、自プロセス以外のディレクトリにはなるべく書き込み権限を与えないようにする必要がありそうです。

そこで、次のバージョンでは、パス名を導出する際に、「/proc/自プロセスのプロセスID/」ディレクトリを特例として「/proc/self/」ディレクトリにマッピングすることにしました。これは、「TOMOYO Linux のパス名の最後の / より前にシンボリックリンクが含まれることは無い」という規則に違反することになりますが、以下のようなメリットが生まれます。

  • 自分以外のプロセスの情報にアクセスする必要が無ければアクセスを禁止することができる
  • allow_read で自プロセスに関する情報の参照を許可することができる
posted by 熊猫さくら at 20:18| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月26日

オンラインアップデートを行う際の注意点

ここに書かれている内容は現時点における考え方です。絶対に安全確実であると断言できる方法ではなく、また、最善の方法であるとは限りません。

/sbin/init が使用するファイルがアップデートされた場合、 /sbin/init をリロードするために /sbin/init から /sbin/init が起動されるので、 /sbin/init が実行されるドメインに対して /sbin/init の実行許可を与えてください。具体的には、以下のようなアクセス許可をドメイン用ポリシーファイルに追加してください。

<kernel> /sbin/init
1 /sbin/init

「<kernel> /sbin/init」から /sbin/init が実行されると「<kernel> /sbin/init /sbin/init」というドメインに遷移してしまうので、それを避けるために /sbin/init を initializer として指定してください。以下のような指定を例外ポリシーファイルに指定することで、 /sbin/init がリロードされた場合でも「<kernel> /sbin/init」ドメインで動作するようにできます。

initializer /sbin/init

また、デーモン系プログラムをアップデートした場合、 /etc/init.d/ ディレクトリ以下の起動・終了スクリプトを使用して restart や reload 等が実行されます。そのため、システムの起動時に実行される start とシャットダウン時に実行される stop だけでなく、 restart や reload 等に必要なアクセス許可も学習させておいてください。
( /etc/init.d/ ディレクトリ以下の起動・終了スクリプトを initializer から除外あるいは信頼済みドメインに指定する方法でも構いません。ただし、対象となるデーモンプログラムが信頼済みドメインで動作してしまうと強制アクセス制御による保護ができないため、対象となるデーモンプログラムを initializer に指定するようにしてください。)

なお、ソフトウェアのアップデートのために一時的にサービスを停止させても構わない場合、上記の方法よりも以下の手順を採用するほうが良いと思います。(この場合でも start や stop に必要なアクセス許可は学習させておく必要があります。)

  • アップデート対象となるパッケージをダウンロードする
  • /etc/init.d/ ディレクトリ以下の起動・終了スクリプトを使ってサービスを停止させる
  • アップデート対象となるパッケージをインストールする
  • /etc/init.d/ ディレクトリ以下の起動・終了スクリプトを使ってサービスを開始させる
posted by 熊猫さくら at 00:51| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月25日

共有ライブラリの自動登録について

今週は、 ldconfig -NXp で出力されるファイル(実際にはシンボリックリンクなのでそのリンク先のファイル)を自動的に allow_read に登録するためのデーモンプログラムについて検討しています。 先日のバージョンとの違いは、「シンボリックリンクの一覧をファイルシステムから取得しないので動作が軽い」「ポリシーで allow_read に指定されていないものであっても登録するため、新たなシンボリックリンクが追加された場合でも(そのファイルが ldconfig により /etc/ld.so.cache に登録されている限り)対応できる」の2点です。

Linux では、「データファイルが漏洩したり改ざんされたりするのは困るが、ライブラリファイルは(誰でも自由に入手できるから)漏洩しても困ることは少ない」という事が言えると思います。そのため、「 /etc/ld.so.cache に登録されているライブラリファイルは、不特定多数のプログラムから参照できるように allow_read で指定しておいても大丈夫だろう」と考えています。なお、「このライブラリファイルは /etc/ld.so.cache に登録されているけども不特定多数のプログラムから参照できるようにはしたくない」という場合に備え、コマンドライン引数から特定のファイルを除外できるようにしてあります。

ISO イメージからインストールした Fedora Core 4 を yum -y update で最新状態にアップデートするという方法を試してみました。その結果、 /etc/ld.so.cache に登録されているファイルにアクセスできないというエラーは発生しませんでした。ただし、サービスの再起動や設定ファイルの再読み込みに必要なアクセス許可を学習させていなかったため、その他のエラーが発生しました。これらのエラーへの対処方法は次回説明します。

次回リリース時にこのプログラムを含めたいと思っていますが、オンラインアップデートをスムーズに行えるようにするにはもう少し検討が必要です。

posted by 熊猫さくら at 21:23| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月24日

spamassassin の扱いについて

スパムメールフィルタの spamassassin はデフォルトで /tmp/ ディレクトリにテンポラリのディレクトリを作成します。ただし、使われるディレクトリ名はバージョンによって異なっているようです。

RedHat Linux 9 に含まれている spamassassin では以下のようなパターンを使用します。

file_pattern /tmp/spamassassin-\$/
file_pattern /tmp/spamassassin-\$/.spamassassin/
file_pattern /tmp/spamassassin-\$/.spamassassin/auto-whitelist\*

Fedora Core 3 や Debian Sarge に含まれている spamassassin では以下のようなパターンを使用します。

file_pattern /tmp/spamd-\$-init/
file_pattern /tmp/spamd-\$-init/.spamassassin/
file_pattern /tmp/spamd-\$-init/.spamassassin/\*

上記は何も設定せずにデーモンを起動させただけで必要になるパターンです。実際にはもっとたくさんのパターンを指定する必要があるかもしれません。

posted by 熊猫さくら at 20:09| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月23日

squid の扱いについて

プロキシサーバの squid はキャッシュを保存するためのディレクトリをたくさん(デフォルトで16×256=4096個)作成します。 そのため、例外ポリシーでパターン化しておく必要があります。
キャッシュ用ディレクトリの場所とディレクトリの数は /etc/squid/squid.conf の cache_dir ディレクティブで指定されています。
キャッシュの保存場所が /var/spool/squid/ の場合、以下のようなパターンを例外ポリシーに指定してください。

file_pattern /var/spool/squid/\*/
file_pattern /var/spool/squid/\*/\*/
file_pattern /var/spool/squid/\*/\*/\*

/usr/sbin/squid の子プロセスとして起動される /usr/lib/squid/unlinkd (ファイルを削除するためのデーモン)に対してはファイルを削除するのに必要なアクセス許可を与えてください。
(バージョン 1.0.2 までの場合は allow_unlink ではなく 2 になります。)

allow_unlink /var/spool/squid/\*/\*/\*
posted by 熊猫さくら at 20:09| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月22日

Fedora Core 5 の readahead の扱いについて

Fedora Core 5 には、よく使われるファイルを予めRAM上にロードしておくことで動作を高速化させるための readahead というパッケージが付属しています。

/usr/sbin/readahead は /etc/rc.d/init.d/ ディレクトリにある起動スクリプトから実行され、 /etc/readahead.early.files および /etc/readahead.files に指定されているファイルに対して読み込みアクセスを行います。しかし、これらのファイルには多数のプログラムや設定ファイル等が指定されているため、 http://kumaneko-sakura.sblo.jp/article/328952.html で紹介した prelink と同様、パス名を保持するために大量のメモリを消費してしまうという問題を抱えています。

この問題を回避する方法は2通りです。簡単な方法は、以下のように chkconfig を使ってこれらのサービスが実行されないようにすることです。

chkconfig readahead_early off
chkconfig readahead off

http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/fc5/?v=policy-sample に置いてあるポリシーのサンプルでは、この方法を採用しました。

もう1つの方法は、 /etc/readahead.early.files および /etc/readahead.files の内容を参考にしながら、 /usr/sbin/readahead のドメインに対してパターン化したアクセス許可を与えていくことです。いろいろなファイルを参照しているため、かなり緩めのパターン化が必要になると思います。まぁ、書き込みは行わないようなので緩めに許可しても大丈夫だとは思いますが。

posted by 熊猫さくら at 20:30| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月21日

現在までの目次

TOMOYO Linux とは
   http://kumaneko-sakura.sblo.jp/article/275769.html
TOMOYO Linux におけるパス名の表記法について
   http://kumaneko-sakura.sblo.jp/article/275773.html
   http://kumaneko-sakura.sblo.jp/article/277736.html
TOMOYO Linux におけるワイルドカードの使用について
   http://kumaneko-sakura.sblo.jp/article/277737.html
TOMOYO Linux におけるドメインについて
   http://kumaneko-sakura.sblo.jp/article/280111.html
   http://kumaneko-sakura.sblo.jp/article/281966.html
TOMOYO Linux におけるユーザとロールについて
   http://kumaneko-sakura.sblo.jp/article/284840.html
   http://kumaneko-sakura.sblo.jp/article/288778.html
TOMOYO Linux によるログイン認証の強化について
   http://kumaneko-sakura.sblo.jp/article/286949.html
TOMOYO Linux におけるデバイスファイルの保護について
   http://kumaneko-sakura.sblo.jp/article/291615.html
TOMOYO Linux における機能分類について
   http://kumaneko-sakura.sblo.jp/article/293567.html
TOMOYO Linux におけるマウント制限について
   http://kumaneko-sakura.sblo.jp/article/298507.html
   http://kumaneko-sakura.sblo.jp/article/298542.html
SYAORAN ファイルシステムの使い方について
   http://kumaneko-sakura.sblo.jp/article/301456.html
TOMOYO Linux における chroot 制限について
   http://kumaneko-sakura.sblo.jp/article/303669.html
読み込み専用ファイルシステムであることが原因でエラーとなったファイルアクセスを表示する機能について
   http://kumaneko-sakura.sblo.jp/article/303676.html
TOMOYO Linux におけるローカルポート番号の自動割り当ての制限について
   http://kumaneko-sakura.sblo.jp/article/304555.html
TOMOYO Linux における自発的権限放棄機能について
   http://kumaneko-sakura.sblo.jp/article/307244.html
TOMOYO Linux がタスク構造体に注目する理由について
   http://kumaneko-sakura.sblo.jp/article/307247.html
初期制御レベルの指定方法について
   http://kumaneko-sakura.sblo.jp/article/309752.html
ドメイン単位のアクセス制御機能について
   http://kumaneko-sakura.sblo.jp/article/311493.html
制御レベルについて
   http://kumaneko-sakura.sblo.jp/article/313521.html
エラーメッセージの表示について
   http://kumaneko-sakura.sblo.jp/article/313524.html
監査ログ機能について
   http://kumaneko-sakura.sblo.jp/article/315304.html
パス名のパターン化について
   http://kumaneko-sakura.sblo.jp/article/316432.html
無条件読み込み許可について
   http://kumaneko-sakura.sblo.jp/article/316434.html
ファイルに対するアクセス制御機能について
   http://kumaneko-sakura.sblo.jp/article/317819.html
ポリシーを保存する方法について
   http://kumaneko-sakura.sblo.jp/article/321755.html
テンポラリファイルの見つけ方について
   http://kumaneko-sakura.sblo.jp/article/321757.html
ドメイン遷移例外について
   http://kumaneko-sakura.sblo.jp/article/323687.html
信頼済みドメインについて
   http://kumaneko-sakura.sblo.jp/article/326379.html
シャットダウンを行うためのドメインの扱いについて
   http://kumaneko-sakura.sblo.jp/article/326412.html
TOMOYO Linux 上で動作するアプリケーションを開発する上でのお願い
   http://kumaneko-sakura.sblo.jp/article/328945.html
Fedora Core 3 の logrotate を実行するドメインの扱いについて
   http://kumaneko-sakura.sblo.jp/article/328948.html
Fedora Core 3 以降の prelink の扱いについて
   http://kumaneko-sakura.sblo.jp/article/328952.html
Java を使ったアプリケーションの扱いについて
   http://kumaneko-sakura.sblo.jp/article/333643.html
cron が実行するジョブを学習する方法について
   http://kumaneko-sakura.sblo.jp/article/333656.html
ケイパビリティに関する強制アクセス制御について
   http://kumaneko-sakura.sblo.jp/article/335939.html
   http://kumaneko-sakura.sblo.jp/article/339392.html
ローカルポートの使用に関する強制アクセス制御について
   http://kumaneko-sakura.sblo.jp/article/342723.html
リモートポートの使用に関する強制アクセス制御について
   http://kumaneko-sakura.sblo.jp/article/342725.html
シグナルの使用に関する強制アクセス制御について
   http://kumaneko-sakura.sblo.jp/article/342728.html
ポリシーを保存する方法について
   http://kumaneko-sakura.sblo.jp/article/347127.html
ポリシーを再読み込みする方法について
   http://kumaneko-sakura.sblo.jp/article/350063.html
コマンドラインオプションの指定を制限する方法について
   http://kumaneko-sakura.sblo.jp/article/354406.html
機密度に応じた文書の管理方法について
   http://kumaneko-sakura.sblo.jp/article/358391.html
ランダムにネットワークポート番号を選択するサービスについて
   http://kumaneko-sakura.sblo.jp/article/362567.html
HTTP や FTP 等でアクセスを許可するファイルを指定する方法について
   http://kumaneko-sakura.sblo.jp/article/365765.html
バニラカーネル以外への適用について
   http://kumaneko-sakura.sblo.jp/article/367573.html
カーネルの動作確認用のツールについて
   http://kumaneko-sakura.sblo.jp/article/369183.html
ログイン認証の強化(CERBERUS)について
   http://kumaneko-sakura.sblo.jp/article/372199.html
   http://kumaneko-sakura.sblo.jp/article/388532.html
   http://kumaneko-sakura.sblo.jp/article/390597.html
   http://kumaneko-sakura.sblo.jp/article/401950.html
   http://kumaneko-sakura.sblo.jp/article/407594.html
   http://kumaneko-sakura.sblo.jp/article/409826.html
   http://kumaneko-sakura.sblo.jp/article/411897.html
   http://kumaneko-sakura.sblo.jp/article/427594.html
   http://kumaneko-sakura.sblo.jp/article/429562.html
   http://kumaneko-sakura.sblo.jp/article/431430.html
scp/sftp への対処について
   http://kumaneko-sakura.sblo.jp/article/434756.html
ssh/scp/sftp の自動実行について
   http://kumaneko-sakura.sblo.jp/article/438146.html
パターンマッチングについて
   http://kumaneko-sakura.sblo.jp/article/440824.html
   http://kumaneko-sakura.sblo.jp/article/442394.html
シャットダウン処理について
   http://kumaneko-sakura.sblo.jp/article/446683.html
cardmgr が作成するデバイスファイルについて
   http://kumaneko-sakura.sblo.jp/article/449167.html
Targeted Policy の作り方について
   http://kumaneko-sakura.sblo.jp/article/450207.html
logrotate のアクセス許可を学習させる方法について
   http://kumaneko-sakura.sblo.jp/article/454136.html
anacron のアクセス許可を学習させる方法について
   http://kumaneko-sakura.sblo.jp/article/454139.html
効率的にパス名のパターン化を行う方法について
   http://kumaneko-sakura.sblo.jp/article/459882.html
gcc が使用するパス名のパターン化について
   http://kumaneko-sakura.sblo.jp/article/461913.html
詳細な書き込みアクセス権限のチェックについて
   http://kumaneko-sakura.sblo.jp/article/463433.html
バニラカーネル以外への適用について
   http://kumaneko-sakura.sblo.jp/article/470145.html
Shared Subtree のサポートについて
   http://kumaneko-sakura.sblo.jp/article/475717.html
cron のアクセス許可を学習させる方法について
   http://kumaneko-sakura.sblo.jp/article/477221.html
パッケージのアップデートに伴うパス名の変化について
   http://kumaneko-sakura.sblo.jp/article/479846.html
   http://kumaneko-sakura.sblo.jp/article/485792.html
posted by 熊猫さくら at 11:34| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月20日

パッケージのアップデートに伴うパス名の変化について(続)

TOMOYO Linux はパス名(ディレクトリ名+ファイル名)に基づくアクセス制御を行うため、パッケージのアップデート等によりパス名が変化した場合には、ポリシーを更新する必要があります。

共有ライブラリの場合、パス名の内、ファイル名の部分だけが変化します。(逆に、ディレクトリ名が変化することはまずありません。)ほとんどの共有ライブラリはシンボリックリンクを経由してアクセスされます。そのため、バージョンアップをしても、シンボリックリンクのリンク先が変化するだけで、シンボリックリンク自体のパス名は変化しません。つまり、シンボリックリンクのリンク先がどのように変化するかを監視するのが有効であり、機械的に変化を一覧表示することができます。

先週から、シンボリックリンクの一覧を取得し、そのリンク先が allow_read で指定されたファイルであるものに関して、リンク先が更新された場合に新しいリンク先を指定して allow_read の登録を行うためのデーモンプログラムについて検討しています。
このデーモンを起動してからアップデートを実行することで、シンボリックリンクのリンク先が変化するだけの更新(新たなシンボリックリンクの追加を伴わない更新)であれば自動的に allow_read を更新することができるようになります。
allow_read には、主に ldconfig に登録されている共有ライブラリを指定するため、一瞬でもアクセスできなくなるとプログラムを実行できなくなってしまう可能性があります。そのため、 allow_read で指定されるファイルは即時に最新のパス名を指すようにする必要があります。
カーネル 2.4 系でも動く必要がある点と、 dnotify の使い方を理解していないので、1秒間隔のポーリングという非効率的な方法で実現しています。ポーリング方式なので、約1秒の遅延が起きてしまうのが心配です。この遅延時間が許容範囲なのかどうかは今後実験して確かめる予定です。

posted by 熊猫さくら at 21:27| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月19日

パッケージのアップデートに伴うパス名の変化について

TOMOYO Linux はパス名(ディレクトリ名+ファイル名)に基づくアクセス制御を行うため、パッケージのアップデート等によりパス名が変化した場合には、ポリシーを更新する必要があります。

安全確実な方法は、パッケージのダウンロードまでを行い、安全な環境を用意(ネットワークから切断)した上で「確認モード」に変更してからパッケージのアップデートを行い、アップデートされたアプリケーションを実際に動作させてアクセス許可の不足がないかどうかを確認することです。
VMware 等、同一ハードウェア構成の環境を2台用意できる場合は、コピーされた環境に対してアップデートを行い、アクセス許可の不足がないかどうかを確認することができます。

しかし、アップデート前後でパス名がどのように変化するかを予め把握できている場合には、アップデート前にポリシーファイルに新しいパス名を追加して再読み込みする方法も使えます。 ただし、パス名が変化するだけでなく、依存関係も変化する場合もありえますので、絶対確実な方法とは言えません。

Windows ではライブラリファイルのバージョンはファイルの中に埋め込まれているので、バージョンアップしてもパス名が変化することは滅多にありません。
TOMOYO Linux としては、 Windows のようにライブラリファイルのパス名が固定されているほうが嬉しいわけです。

posted by 熊猫さくら at 09:43| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月18日

cron のアクセス許可を学習させる方法について

http://kumaneko-sakura.sblo.jp/article/333656.html で cron が実行するジョブに必要なアクセス許可を学習させる2通りの方法を紹介しましたが、次回の手順書では /etc/crontab を編集する方法を採用することにしました。

/etc/crontab を開き、以下のようにジョブの実行間隔を5分に変更してください。 1分間隔だと前回のジョブが終了する前に次回のジョブが開始されてしまう可能性が高いので、適当な時間間隔を設定する必要があります。 pstree を実行すると、 cron のジョブを実行中かどうか確認できます。もし、 pstree を実行すると常に cron のジョブが表示されるようであれば、時間間隔を長くしてください。

変更前
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

変更後
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
*/5 * * * * root run-parts /etc/cron.hourly
*/5 * * * * root run-parts /etc/cron.daily
*/5 * * * * root run-parts /etc/cron.weekly
*/5 * * * * root run-parts /etc/cron.monthly

この状態でしばらく放置して、必要なアクセス許可が学習されるのを待ちます。

強制モードでの稼動を始める前までに、 /etc/crontab に加えた変更を元に戻すようにしてください。

posted by 熊猫さくら at 09:08| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月17日

Shared Subtree のサポートについて

カーネル 2.6.15 では shared subtree という機能が追加されました。
これは、マウントポイント単位で共有するしない等を設定することで、 それぞれのプロセスが異なる名前空間を持っていても(例えば) CD-ROM にアクセスするために使われるマウントポイントを それぞれのプロセスから共通してアクセスできるようにする機能のようです。 (詳しいことは私もまだ理解していません。)

そのために、 mount 操作に対していくつかの構文が追加されたのですが、 TOMOYO Linux version 1.0.2 のマウント制限機能では新しい構文を認識していませんでした。
次のバージョンでは新しい構文を認識できるようになります。

posted by 熊猫さくら at 19:41| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月16日

バニラカーネル以外への適用について

http://kumaneko-sakura.sblo.jp/article/367573.html でバニラカーネル以外のカーネルに対して TOMOYO Linux のパッチを適用することについて触れました。 その後もパッチの作成を続けており、3/14現在、以下のバージョン用のパッチがあります。

RedHat Linux 9 用

  • 2.4.20-43.9.legacy

Debian Sarge 用

  • 2.4.27-10sarge1
  • 2.6.8-16sarge1

Fedora Core 3 用

  • 2.6.12-1.1381_FC3

Fedora Core 4 用

  • 2.6.15-1.1831_FC4

Fedora Core 5 test 3 用

  • 2.6.15-1.1977_FC5
  • 2.6.15-1.2041_FC5

バニラカーネル用

  • 2.4.30
  • 2.4.31
  • 2.4.32
  • 2.6.11
  • 2.6.12
  • 2.6.13
  • 2.6.14
  • 2.6.15
  • 2.6.15.4
  • 2.6.16-rc6

ただし、最終的に次回リリースにどれだけ多くのパッチを含めることができるのかはまだ不明です。

posted by 熊猫さくら at 00:06| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月15日

詳細な書き込みアクセス権限のチェックについて

次期バージョンでは、詳細な書き込みアクセス権限のチェックを行えるようにする予定です。

version 1.0.2 まではファイルやディレクトリに対するアクセス許可の粒度は read/write/execute の3種類のみでした。そのため、 write 権限の中には

  • open(O_WRONLY)
  • open(O_RDWR の WR 部分)
  • open(O_TRUNC)
  • open(O_CREAT)
  • sysctl(WRITE)

の他に

  • mkdir
  • rmdir
  • unlink
  • mksock
  • mkfifo
  • mkchar
  • mkblock
  • link
  • symlink
  • rename
  • create
  • truncate

が含まれていました。

しかし、あるファイルへの write 権限があればそのファイルを削除して同名の異なるファイルを作成できてしまうのはセキュリティ上危険です。例えば、通常ファイルを削除して、同じ名前でハードディスクを指すブロックデバイスファイルを作成される可能性があります。通常のファイルを読み書きする許可を意図していたのに、侵入者がファイルを作り直すことで、そのパス名を使ってハードディスクを直接読み書きできるような状況が起こりうるのです。

このような状況が発生する可能性を減らすために、ケイパビリティ(http://kumaneko-sakura.sblo.jp/article/335939.html)を使ってデバイスファイルを作成することができるドメインを制限していましたが、パス名による制限ではないため充分とはいえない状況でした。

次のバージョンでは write 権限は以下の3種類だけを指すようになります。

  • open(O_WRONLY)
  • open(O_RDWR の WR 部分)
  • sysctl(WRITE)

そして、新規に以下の権限が追加されます。

  • allow_mkdir
  • allow_rmdir
  • allow_unlink
  • allow_mksock
  • allow_mkfifo
  • allow_mkchar
  • allow_mkblock
  • allow_link
  • allow_symlink
  • allow_rename
  • allow_create
  • allow_truncate

これらの細分化された書き込みアクセス権限のチェックが行われるようになることで、パス名による制限ができるようになります。(実際には「キャラクタ型デバイスファイル」「ブロック型デバイスファイル」という種別だけでは不十分かもしれませんが、現時点ではデバイス番号まではチェックしていません。今後、必要であると判断したらチェックするようにしようと思います。)

実際にこれらの権限を有効にした状態で取得したポリシーのサンプルを http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/?v=policy-sample で眺めることができます。

posted by 熊猫さくら at 08:22| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月14日

gcc が使用するパス名のパターン化について

gcc が利用可能な状態でサーバとして動作させるというのはセキュリティ上望ましくないのですが、やむを得ず gcc を利用可能な状態にする必要がある場合、 gcc を実行するためのドメインに対して環境変数 TEMP または TMP を明示することを推奨します。

例えば、

gcc -Wall -O3 test.c

を実行すると /tmp/ 直下に cc\?\?\?\?\?\?.c cc\?\?\?\?\?\?.o cc\?\?\?\?\?\?.s cc\?\?\?\?\?\?.le cc\?\?\?\?\?\?.ld 等のパターンを持った一時ファイルが生成されます。そのため、

file_pattern /tmp/cc\?\?\?\?\?\?.\*

というパターンでグループ化することができます。しかし、 gcc とは無関係なプログラムがこのようなパターンを必要とした場合、 gcc が生成した一時ファイルにもアクセスできるようになってしまいます。そのため、 /tmp/ 直下ではなく例えば /tmp/gcc/ 直下に一時ファイルが作成されるように

TMP=/tmp/gcc/ gcc -Wall -O3 test.c
# または
TEMP=/tmp/gcc/ gcc -Wall -O3 test.c

のように環境変数を指定した上で gcc を実行することで

file_pattern /tmp/gcc/cc\*

のように gcc 専用のパターンでグループ化できるようになるため、 gcc に関連する一時ファイルに他のプログラムからアクセスできるようになってしまう可能性を低くすることができます。( /tmp/gcc/ ディレクトリは予め作成しておいてください。)

なお、この手法は gcc のみに限定されるものではなく、環境変数を使って一時ファイルを作成する場所を指定できるプログラム全般に適用できます。

posted by 熊猫さくら at 19:43| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月13日

効率的にパス名のパターン化を行う方法について

ポリシー策定作業で面倒なのは、パス名のパターンを見つけ、例外ポリシーに追加することだと思います。この作業を効率的に行うために、画面を3つ用意して使い分けることをお勧めします。
1番目の画面は、ポリシー違反ログを表示させるためだけに使用します。 2番目の画面は、ポリシーエディタを実行するためだけに使用します。 3番目の画面は、実際の操作を行うためだけに使用します。

まず、ポリシー違反ログが現在操作中の画面に表示されてしまうと邪魔なので、プロファイルで TOMOYO_VERBOSE=0 を指定しておきます。

次に、 http://kumaneko-sakura.sblo.jp/article/315304.html で紹介したように、 ccs-auditd を使ってポリシー違反ログがファイルに保存されるようにします。 具体的には、 /etc/rc.local 等から

/root/ccstools/ccs-auditd /dev/null /var/log/tomoyo/reject_log.txt

のように指定します。( /var/log/tomoyo/ ディレクトリは予め作成しておいてください。)

再起動後、1番目の画面では、以下のコマンドを実行してください。

tail -f /var/log/tomoyo/reject_log.txt

こうすることで、1番目の画面にはポリシー違反ログが表示されるようになります。

2番目の画面では、以下のコマンドを実行してください。

/root/ccstools/editpolicy

こうすることで、2番目の画面はポリシーを編集するための画面になります。ポリシーエディタでは、 Tab キーを押すことで「システムポリシー」「例外ポリシー」「ドメインポリシー」の順番で画面を切り替えることができます。

3番目の画面では、実際にパス名のパターン化が必要になる操作を行います。実際に操作する内容としては、昨日紹介した logrotate や anacron 等があります。一度で全てのパターンを検出できるとは限らないので、何度か繰り返してください。

この3つの画面はローカルコンソールから「Alt + F1」〜「Alt + F3」を使って切り替えて使用しても良いのですが、複数のウィンドウを部分的に重ねて表示できる環境があると便利です。 私の場合、 Windows XP から(TeraTerm が作成した) ssh のウィンドウを2つ用意して作業しています。 TOMOYO Linux カーネルで動作中のPCと Windows XP のPCの両方が視界に入る位置に配置しているので、 1番目の画面を使用する代わりにプロファイルで TOMOYO_VERBOSE=1 を指定してコンソールに直接表示されるようにしています。 そして、コンソールに違反メッセージが表示されなくなるまでパターン化作業を続けます。

なお、ログイン認証の強化を使用している場合は、次の点に注意してください。

パターンを洗い出す作業を行っている間は、ログイン直後のドメインからポリシーエディタを実行しても構いません。しかし、本番用のポリシーを学習させる作業を行う場合には、追加のログイン認証を通過後のドメインから実行するようにしてください。なぜなら、ポリシーエディタを実行できるドメインでは、例外ポリシーに「trust_domain <kernel>」を追加することで TOMOYO Linux のアクセス制御を無力化することができるからです。追加のログイン認証を通過する前のドメインからポリシーエディタが実行可能な状態だと、追加のログイン認証も無力化されてしまいます。

posted by 熊猫さくら at 20:05| Comment(0) | TrackBack(0) | TOMOYO Linux

2006年03月12日

anacron のアクセス許可を学習させる方法について

コマンドラインから anacron を起動して必要なアクセス許可を学習させる方法を使うので、 /etc/init.d/anacron から起動された場合でもコマンドラインから起動された場合でも同一のドメインで動作するように指定します。具体的には、 /usr/sbin/anacron を initializer として例外ポリシーに登録しておきます。

initializer /usr/sbin/anacron

コマンドラインから anacron を起動し、必要なアクセス許可を学習させます。現在のシステム時刻に関係なく anacron のジョブを実行させるために、 -d -f -n オプションを指定してください。

anacron -dfn
posted by 熊猫さくら at 12:29| Comment(0) | TrackBack(0) | TOMOYO Linux

logrotate のアクセス許可を学習させる方法について

Fedora Core 3 の場合は http://kumaneko-sakura.sblo.jp/article/328948.html を参照ください。

コマンドラインから logrotate を起動して必要なアクセス許可を学習させる方法を使うので、 cron から起動された場合でもコマンドラインから起動された場合でも同一のドメインで動作するように指定します。具体的には、 /usr/sbin/logrotate を initializer として例外ポリシーに登録しておきます。

initializer /usr/sbin/logrotate

コマンドラインから logrotate を起動し、必要なアクセス許可を学習させます。現在のシステム時刻に関係なく logrotate のジョブを実行させるために、 -f オプションを指定してください。

/usr/sbin/logrotate -f /etc/loglotate.conf
posted by 熊猫さくら at 12:28| Comment(0) | TrackBack(0) | TOMOYO Linux