2011-03-01 :-(
_ 午後
1300 実機
_ 夜やる暇がないならば朝やればいいじゃない
定時退勤してたときは帰宅後 録画しておいたアニメを見ながら筋トレ( ref. アニメダイエット ) してたんだが最近は帰宅後にそーいう時間を作れないので朝やってる。
平日の夜 23 時ころからの NHK 総合 Bizスポ を録画しておき、翌日朝は 1.5 倍速で再生しながら Biz 部だけ(スポーツ部は興味ないので見てない)見ながら筋トレ。これで 10 分くらい。毎日 10 分くらいの筋トレ時間でる。
ただし今度はアニメを見てる暇がないので録画したアニメが溜まってしまう。
_ [NetBSD][systrace][翻訳]Systrace Policies - O'Reilly Media
Systrace ポリシー
by Michael W. Lucas
01/30/2003
One of the more exciting new features in NetBSD and OpenBSD is systrace(1), a system call access manager. With systrace, a system administrator can say which system calls can be made by which programs and how those calls can be made. Proper use of systrace can greatly reduce the risks inherent in running poorly-written or exploitable programs. systrace policies can confine users in a manner completely independent of Unix permissions. You can even define the errors that the system calls return when access is denied, to allow programs to fail in a more proper manner. Proper use of systrace requires a practical understanding of system calls, what programs must have to work properly, and how these things interact with security.
NetBSD と OpenBSD のより興奮する機能の 1 つは、システムコールアクセスマネージャー systrace(1) だ。systrace を使うと、システム管理者はプログラムから呼び出されるシステムコールと、それがどのように呼び出されるかを見ることができる。systrace は、ダサいコーディングだったり脆弱性があるプログラムに潜むリスクを軽減するために使うととてもよい。systrace の方針は、Unix のパーミッションに完全に依存したユーザー制限をするようになっている。システムコールが「アクセスが拒否された」というエラーを返させるようにするには、より適切な方法でプログラムが失敗するようにすればよい。systrace を使うときは、実際のシステムコールを理解し、プログラムを正しく動作させず、セキュリティにどう影響するのかを把握しておかなければならない。
First off, what are system calls? Sysadmins fling that term around a lot, but many of them don't know exactly what it means. A system call is a function that lets you talk to the operating system kernel. If you want to allocate memory, open a TCP/IP port, or perform input/output on the disk, that's a system call. System calls are documented in section 2 of the online manual.
まず、システムコールとはなんぞや? システム管理者たちはよくこの言葉を使うが、彼らのうち意味をちゃんと知っているものはほとんど居ない。システムコールとは、オペレーティングシステムのカーネルと会話するときに使うものだ。メモリを確保したいとき、TCP/IP ポートを開きたいとき、ディスクの入出力をしたいときに使う。それがシステムコールだ。システムコールの文書はオンラインマニュアルのセクション 2 にある。
Unix also supports a wide variety of C library calls. These are often confused with system calls but are actually just standardized routines for things that could be written within a program. You could easily write a function to compute square roots within a program, for example, but you could not write a function to allocate memory without using a system call. If you're in doubt whether a particular function is a system call or a C library function, check the online manual.
Unix は多様な C ライブラリコールにも対応している。これらはたまにシステムコールとごっちゃにされるが、これはプログラムの範囲内で使われるためのたんなる標準関数である。平方根を計算する関数は簡単に書けるが、たとえばメモリを確保する処理はシステムコールを使わずに書くことはできない。システムコールを使うにせよ、C ライブラリ関数を使うにせよオンラインマニュアルを読むこと。
You may find an occasional system call that is not documented in the online manual, such as break(). You'll need to dig into other resources to identify these calls. (break() in particular is a very old system call used within libc, but not by programmers, so it seems to have escaped being documented in the man pages.)
break() のように、たまにオンラインマニュアルに存在しないシステムコールを見かけるかもしれない。こういったシステムコールについては別の文書を参照する( break() はプログラマ向けではなく、libc で使われていたとても古いシステムコールである。なので man ページから削除された )。
systrace denies all actions that are not explicitly permitted and logs the rejection to syslog. If a program running under systrace has a problem, you can find out what system call the program wants and decide if you want to add it to your policy, reconfigure the program, or live with the error.
systrace の動作は不明確な権限で制限されており、ログを syslog に書けない。systrace の下で走っているプログラムに問題が発生したら、プログラムが使おうとしているシステムコールを調べ、必要であればポリシーに追加し、プログラムを設定しなおすか、エラーを放置しておく。
systrace has several important pieces: policies, the policy generation tools, the runtime access management tool, and the sysadmin real-time interface. This article gives a brief overview of policies. Next time, we'll learn about the systrace tools.
systrace はいくつか重要な事項がある。ポリシー、ポリシー生成ツール、実行時アクセス制御ツール、そしてシステム管理者向けリアルタイムインターフェースだ。ここではポリシーの概要を説明する。次回に systrace ツールについて学ぶ。
Reading systrace Policies (systrace ポリシーを読む)
The systrace(1) manual page includes a full description of the syntax used for policy descriptions, but I generally find it easier to look at some examples of a working policy and then go over the syntax in detail. Since named has been a subject of recent security discussions, let's look at the policy that OpenBSD 3.2 provides for named.
systrace(1) マニュアルページはポリシーを使う上での構文の全説明が載っている。ポリシーを運営するためのサンプルが簡単に見つかるし、構文の詳細も分かる。named の最近のセキュリティー議論については、 OpenBSD 3.2 の named のポリシーを参照。
Before reviewing the named policy, let's review some commonly-known facts about the name server daemon's system access requirements. Zone transfers occur on port 53/TCP, while basic lookup services are provided on port 53/UDP. OpenBSD chroots named into /var/named by default and logs everything to /var/log/messages. We might expect system calls to allow this access.
named のポリシーを読む前に、ネームサーバーデーモンが要求するアクセスについて一般的な状況を読もう。ゾーン転送は 53/TCP で使い、基本的な名前解決サービスは 53/UDP を使う。OpenBSD では named は既定で /var/named に chroot し、すべてのログは /var/log/messages に書かれる。これらにアクセスするシステムコールを許可すればよい。
Each systrace policy file is in a file named after the full path of the program, replacing slashes with underscores. The policy file usr_sbin_named contains quite a few entries that allow access beyond this, however. The file starts with:
systrace ポリシーのファイルは named のフルパス( スラッシュはアンダースコアに置換する )のあとに繋げられる。usr_sbin_named ポリシーファイルには以下のようにいくつかのエントリーを含む。ファイルの冒頭はこう。
# Policy for named that uses named user and chroots to /var/named # This policy works for the default configuration of named. Policy: /usr/sbin/named, Emulation: native
The "Policy" statement gives the full path to the program this policy is for. You can't fool systrace(1) by giving the same name to a program elsewhere on the system. The "Emulation" entry shows which ABI this policy is for. Remember, BSD systems expose ABIs for a variety of operating systems. systrace can theoretically manage system call access for any ABI, although only native and Linux binaries are supported at the moment.
Policy 文はこのポリシーで扱うプログラムへのフルパスを書く。システムの別のところに同じ名前のプログラムがある、なんてことはないように。Emulation エントリーはこのポリシーの ABI を意味する。BSD システムには様々な ABI があることを忘れないように。systrace は理論上はあらゆる ABI へアクセスするシステムコールを制御できるのだが、ネイティブだけであり、Linux バイナリ対応はもう少しかかる。
The remaining lines define a variety of system calls that the program may or may not use. The sample policy for named includes 73 lines of system call rules. The most basic look like this.
remaining 行はプログラムが使用するか、または使用しそうなシステムコールを定義する。named のサンプルポリシーでは 73 行のシステムコールの規則がある。最も基本的なものは以下のようになる。
native-accept: permit
When /usr/sbin/named tries to use the accept() system call, under the native ABI, it is allowed. What is accept()? Run man 2 accept and you'll see that this accepts connections on a socket. A nameserver will obviously have to accept connections on a network socket!
/usr/sbin/named がネイティブ ABI の下で accept() システムコールを使おうとしたときは許可される。accept() って? man 2 accept を実行すれば、これは socket 接続を受け入れるものだということが分かる。ネームサーバーがネットワークソケットの接続を受け入れることは明らかだからだ。
Other rules are far more restrictive. Here's a rule for bind(), the system call that lets a program request a TCP/IP port to attach to.
他にも制限するルールがある。bind() のルールだ。bind() はプログラムからの TCP/IP ポートへのリクエストをアタッチするシステムコールだ。
native-bind: sockaddr match "inet-*:53" then permit
sockaddr is the name of an argument taken by the accept() system call. The fnmatch keyword tells systrace to compare the given variable with the string inet-*:53, according to the standard shell pattern-matching (globbing) rules. So, if the variable sockaddr matches the string inet-*:53, the connection is accepted. This program can bind to port 53, over both TCP and UDP protocols. If an attacker had an exploit to make named(8) attach a command prompt on a high-numbered port, this systrace policy would prevent that exploit from working -- without changing a single line of named(8) code!
sockaddr は accept() システムコールに渡す引数の名前である。fnmatch は、systrace に渡された変数名と inet-*:53 という文字列を比較する。標準シェルのパターンマッチ (globbing) のルールどおりのものだ。つまり、sockaddr 変数が inet-*:53 文字列にマッチしたら、接続は許可される。このプログラムはポート 53 に bind でき、TCP と UDP の両方を扱える。攻撃者が、大きいポート番号を使うようにした named(8) を使ってコマンドプロンプトから攻撃をしてきた場合、この systrace ポリシーは named(8) を 1 行も変えることなく攻撃を防ぐのだ!
native-chdir: filename eq "/" then permit native-chdir: filename eq "/namedb" then permit
At first glance, this seem wrong. The eq keyword compares one string to another and requires an exact match. If the program tries to go to the root directory, or to the directory /namedb, systrace will allow it. Why would you possibly want to allow named to access to the root directory, however? The next entry explains why.
一見するとこれは失敗するように見える。eq キーワードは 1 文字と厳密に比較する。プログラムがルートディレクトリや、/namedb ディレクトリに行こうとすると、systrace は許可するだろう。なぜ named によるルートディレクトリアクセスを許可するのかって? これから説明しよう。
native-chroot: filename eq "/var/named" then permit
We can use the native chroot() system call to change our root directory to /var/named, but to no other directory. At this point, the /namedb directory is actually /var/named/namedb, which is a sensible location for a chrooted named(8) to access. We also know that named(8) logs to /var/log/messages, however. How does that work, if the program is chrooted to /var/named?
ルートディレクトリを /var/named に限定するためにネイティブの chroot() システムコールを使う。ここで、/namedb ディレクトリは実は /var/named/namedb である。chroot された named(8) は、これでもうまくアクセスできるのである。また、named(8) のログは /var/log/messages に吐かれるわけだが、プログラムが /var/named に chroot した場合にこれがどう動作するのだろうか?
native-connect: sockaddr eq "/dev/log" then permit
This program can use the native connect(2) system call to talk to /dev/log and only /dev/log. That device hands the connections off elsewhere. If you didn't know that this was how the program logged, however, you'd be confused. Although the program is running in a changed root, /dev/log is opened before the chroot happens and chroot(2) does not revoke access to open files outside the chrooted area.
プログラムで使うネイティブの connect(2) システムコールは、 /dev/log とだけ通信できる。このデバイスはどこにも接続されていない。プログラムがどうやってログするのか分からないと混乱するだろう。プログラムは変更した root で走っているわけだが、/dev/log は chroot される前に開かれ、そして chroot(2) は chroot 外で開かれたファイルへのアクセスを拒否しないのである。
We'll also see some entries for system calls that do not exist.
システムコールが存在しない場合についても見てみよう。
native-fsread: filename eq "/" then permit native-fsread: filename eq "/dev/arandom" then permit native-fsread: filename eq "/etc/group" then permit
systrace aliases certain system calls with very similar functions into groups. You can disable this functionality with a command-line switch and only use the exact system calls you specify, but in most cases these aliases are quite useful and shrink your policies considerably. The two aliases are fsread and fswrite. fsread is an alias for stat(), lstat(), readlink(), and access(), under the native and Linux ABIs. fswrite is an alias for unlink(), mkdir(), and rmdir(), in both the native and Linux ABIs. As open() can be used to either read or write a file, it is aliased by both fsread and fswrite depending on how it is called. So named(8) can read certain /etc files, it can list the contents of the root directory, and it can access the groups file.
systrace は、グループの中 { /etc/group か??? }の関数で共通していると思われるシステムコールがあると別名を作る。この機能はコマンドラインスイッチで無効にでき、明記しておいたシステムコールにだけ適用される。これらの別名はけっこう有用で、ポリシーを削減するのに役立つ。fsread と fswrite という 2 つの別名がある。fsread は、ネイティブな Linux ABI における stat()、lstat()、readlink()、access() の別名である。fswrite は、unlink()、mkdir()、そして rmdir() の別名であり、双方ともネイティブの Linux ABI である。open() のように、ファイルの読み書き両方に使えるものは、fsread と fswrite の両方に別名が作られ、呼ばれた方法によってどちらが使われるのか決まる。だから named(8) は /etc のファイルを読めるし、ルートディレクトリ以下の内容を列挙できるし、 groups ファイルにアクセスできるのである。
systrace supports two optional keywords at the end of a policy statement, errorcode and log.
systrace は、ポリシーの文の末尾の errorcode と log というキーワードに対応している。
The errorcode is the error that is returned when the program attempts to access this system call. Programs will behave differently depending on the error that they receive; named will react differently to a "permission denied" error than it will to an "out of memory" error. You can get a complete list of error codes from errno(2). Use the error name, not the error number. For example, here we return an error for non-existent files.
errorcode はプログラムがシステムコールにアクセスしたときに返すエラーである。プログラムは、受け取ったエラーによって挙動が変わる。named は "permission denied" エラーを受け取ったときと、"out of memory" エラーを受け取ったときでは挙動が異なるのである。完全なエラーコードの一覧は errono(2) で得られる。エラー番号ではなく、エラー名を使いなさい。たとえばファイルが存在しないときのエラーの戻り値など。
filename sub "<non-existent filename>" then deny[enoent]
If you put the word log at the end of your rule, successful system calls will be logged. For example, if we wanted to log each time named(8) attached to port 53, we could edit the policy statement for the bind() call to read:
ルールの末尾に log という単語を書いておけばシステムコールが成功したときにログが書かれる。たとえば、named(8) が ポート 53 を使うたびにログするには、bind() のポリシー文を編集すればよい
native-bind: sockaddr match "inet-*:53" then permit log
You can also choose to filter rules based on user ID and group ID, as the example here demonstrates.
また、ユーザーID とグループID をもとにしたフィルタルールを使うこともできる。たとえばこう。
native-setgid: gid eq "70" then permit
This very brief overview covers the vast majority of the rules you will see. As in so many things in computing, systrace does 90% of its work with 10% of its features. For full details on the systrace grammar, read systrace(1). Now that you can recognize a systrace policy when you see one, next time we'll look at some of the tools you can use to create your own policies.
ここでは膨大なルールのうちごく一部を示した。コンピューティングの世界の様々な事柄についても、systrace は、その持つ機能のうち 10% だけが使われ、さらにそのうち 90% が機能している。systrace の全ての文法を知るには systrace(1) を読むとよい。見たいものがあればそこで見ることができる。我々が今度 会うときは、あなた自身のポリシーを作成したときになるだろう。
Michael W. Lucas
