2011-02-03 :-(
2011-02-04 :-)
_ 夜
1830 飯支度
1900 本処分
1930 計算機起動 && インターネット接続
2000 グーグルリーダーの未読が溜まりまくっているので読みまくるなど
2100 飯。豚の角煮
2200 片付け
2300 翻訳 || また公開鍵にアクセスできなくなった orz
2011-02-05 :-)
_ 夜
1900 屋敷新年会
2011-02-06 :-)
_ 午後
1300 兄家族襲来
_ リッジレーサー新作『Ridge Racer Unbounded』PS3/360で登場！ : オレ的ゲーム速報＠刃
( via けやきんとこ )
数日前についったーのタイムラインでチラホラ「リッジ新作」という話題を見かけたんだがまったくウェブ巡回する暇が無かったのでいまさら話題のコレをようやく見たんだが「ゲーム画面もなしに新作とな」と脳内で麻呂が叫んでいる。コメント書いてるひとたちはいったい何をどうやって判断してるんだろう...。
2011-02-07 :-(
2011-02-08 :-(
_ 午後
1400 実機
_ 目が乾く
しぬる
_ d
qmail はもう使ってないけど tinydns は走っており設定ファイルがいまだに覚えられないので( @ + Z . とかいろいろ )そろそろ捨てたいんだがガイアが俺に「動いてるものは触るな」と囁く。
2011-02-09 :-(
_ ,
- 必須
- あると嬉しい → つまり要らない
- 無くてもよい → つまり要らない
_ 俺の屍を越えてゆけ
今日ほど「粉骨砕身」という言葉を嫌悪したときはない
_ [翻訳]An online scheduler for hardware accelerators on general-purpose operating systems - Microsoft Research
汎用オペレーティングシステムでのハードウェアアクセラレーターのためのオンラインスケジューラー
David Sheldon and Alessandro Forin
21 December 2010
This paper presents an online scheduling algorithm for hardware accelerators and its implementation on the NetBSD operating system. The scheduler uses the current performance characteristics of the accelerators to select which accelerators to load and unload. The evaluation on a number of workloads shows that the scheduler is typically within 20% of the optimal schedule computed offline. The hardware support consists of simple cost-benefit indicators, usable for any online scheduling algorithm. The NetBSD modifications consist primarily in loadable kernel modules, with minimal changes to the operating system itself. The measured overhead is negligible when accelerators are not in use, and otherwise scales linearly by a small constant with the number of active accelerators.
この論文は、NetBSD オペレーティングシステムに実装してあるハードウェアアクセラレーターのためのオンラインスケジューリングアルゴリズムについて記述してある。このスケジューリングでは、アクセラレーターがロード/アンロードするために最新の performance characteristics を利用している。いくつかの処理にたいして実験したところ、オフラインで実行したときよりも処理時間が 20% 短くなった。このハードウェアは費用効果の計測機能を搭載していて、あらゆるオンラインスケジューリングアルゴリズムを計測することができる。NetBSD に実装するために多少の変更をしたものが NetBSD に取り込まれている。計測時のオーバーヘッドはアクセラレーターを使ううえでたいした問題にはならないし、いくつかのアクセラレーターは緩く線形増加している。
補足
「オンライン」「オフライン」ってなんのことなのだ、等なにを言ってるのかさっぱりわからん。
_ [OpenSSH][cygwin][ssh]Failed to add the host to the list of known hosts
cygwin の ssh で接続しようとすると怒られる。
% ssh -v miwarin@xxxxxxxxxxxxxxxxxxxx OpenSSH_5.6p1, OpenSSL 0.9.8q 2 Dec 2010 debug1: Connecting to xxxxxxxxxxxxxxxxxxxxxxx [xxx.xxx.xxx.xxx] port 22. debug1: Connection established. : Are you sure you want to continue connecting (yes/no)? yes Failed to add the host to the list of known hosts (/home/rin/.ssh/known_hosts). : debug1: Trying private key: /home/rin/.ssh/id_rsa debug1: Trying private key: /home/rin/.ssh/id_dsa debug1: No more authentication methods to try. Permission denied (publickey).
なんでだろーなんでだろーと悩んでいたんだが
/home/rin/.ssh/id_rsa
アッー
% pwd /cygdrive/c/home/rin
% ln -s /cygdrive/c/home /home
つまりこういうこと
cygwin め...
まあ /etc/fstab 書けよという話なんだが
2011-02-10 :-(
_ 夜
2130 飯。チンジャオロース
_ 機密性
まあ昨日のことなんであるが
新居に来てから初めて雨が降ったんだが家に居る間は雨が降っていることに気付かなかった。旧居は築 30 余年の木造アパートでありすきま風があるし冬になれば凍えるほどになるので雨が降れば屋根を叩く音に気づいたのである。新居は築 10 年くらいの鉄筋マンションであるんだがこれがスゴくてすきま風なんてこれっっっっぽちも無いし暖房が要らないくらいにさっぱり寒くないし雨の音なんてまったくしないのである。つまり外に出るまで雨が降っていることに気付かなかった。機密性が高いというのは冬はありがたいんだが、これはこれで自然から隔離されてるわけなので、もう少し人間としては野性味を持たせないと近いうちに滅びる。滅べば。まあつまり「温室育ち」というのはこういう状態なのだろうよ。
2011-02-12 :-)
_ 夜
1800 コーヒー
1900 ブラタモリ赤坂完全版
2130 マイクロソフトへ質問
2300 PS3 起動してみたら阻止レースやってるらしいので RR7 起動して待機している間に終わってしまったらしいのでジャクチョーさんルームで走っていたら skype 呼ばれたのでいつものメンバーで駄弁るなど。
_ 深夜
0230 RR7 終了。JUJAK + ASTAROTH 3 とか走れなさすぎる。しかし KYO さんが普通に速い。あのひとおかしい。今回は「今日も蹴られやく」「drop する」などといった格言が生まれた。
2011-02-14 :-(
_ 雪、積もってるよ
_ [翻訳][NetBSD][pkgin]NetBSD Blog - pkgin 0.4.0
February 14, 2011 posted by Emile Heitor
After a year of PR's, feedbacks and various fixes, pkgin 0.4.0 is now available and its package, pkgtools/pkgin, is up-to-date.
PR やフィードバックや様々な fix を経て、pkgin 0.4.0 が pkgtools/pkgin にパッケージされ、利用出来るようになった。
For the record, pkgin is a binary package manager aimed at simplifying manipulation of 3rd party software available as pkgsrc binaries. Its usage mimics similar tools like Debian's apt or RedHat's yum. While pkgin does not pretend to be as polished as those well known tools, it is now used in production in various companies (including mine), where clients cannot be told to "wait for the end of the build" ;)
pkgin はサードパーティ製ソフトウェアを pkgsrc バイナリと同じように簡単に扱えることを目的としたバイナリパッケージマネージャ { 「管理ツール」くらいが柔軟か }である。Debian の apt や RedHat の yum のように使える。しかしまだそれらとまったく同じようには使えない。{ 「apt や yum の代わりにはならない」? } いくつかの企業では使われていて( 地雷含む )、「ビルドが終わるまで待ってね」とは言わない。{ プログレスを表示しないとかそういうこと????? }
0.4.0 brings some features that have been requested during the past year such as download-only, package reinstallation, chroot (in order to install packages to a chrooted environment), and bandwith calculation; thanks to Baptiste Daroussin for those two.
pkgin 0.4.0 はダウンロードオンリーだったり、パッケージの再インストールのために chroot が必要だったり( インストールするには chroot 環境が必要なのだ )、豊富な処理能力が必要だったた数年前よりもいくつか機能が追加されている。Baptiste Daroussin に感謝。 { 文の区切りが分からない............ }
pkgin 0.4.0 also has now native support for MINIX 3 thanks to Gautam B.T. from MINIX, and better SunOS 5.1[0-1] support.
pkgin 0.4.0 は Gautam B.T によって MINIX 3 対応した。そして SunOS 5.10, SunOS 5.11 対応もしている。
As of today, i've built and tested pkgin on the following platforms:
pkgin は以下のプラットフォームでビルドされ、テストされている。
- NetBSD 4.0
- NetBSD 5.{0,1}
- NetBSD current
- DragonFly BSD 2.0 to 2.8
- DragonFly BSD current
- Solaris 10/SunOS 5.10
- Opensolaris/SunOS 5.11
- Debian GNU/Linux 5 and 6
- Mac OS X 10.{5,6}
- MINIX 3.1.8
Last but not least, pkgin no longer depends on SQLite package, as the Amalgamation source file is now part of pkgin's tree. That means 0.4.0 binary installation will be as simple as pkg_add http://your.favorite.repository/All/pkgin-0.4.0.tgz
最後に、需要なのだが、pkgin は SQLite に依存しなくなり、Amalgamation ソースファイルが pkgin ソースツリーに取り込まれた。これは、0.4.0 が pkg_add http://your.favorite.repository/All/pkgin-0.4.0.tgz と実行するのと同じように簡単にバイナリインストールできるようになったことを意味する。
As always, testing and feedback is more than appreciated
テストとフィードバックはいつでもどんなものよりも歓迎する。
2011-02-15 :-(
_ 朝
0500 起床
0600 雪積もってるので徒歩
0830 出勤 || 隣の隣のひとの声がシナダ・ベニオ ( シナダ・ベニオ／スカーレットキス )のような感じである。
0930 シミュレーション
_ 午後
1500 実機
2011-02-16 :-(
_ 午後
1500 実機
_ 温故知新
「アセンブラのほうが分かりやすい」というひとの気分が分かる。もしくは「アセンブル後のリストのほうが分かりやすい」「機械語でおｋ」みたいな
_ ,
まあ毎月広告出すなんて枯れた手法だろうけど
_ [Python]Python
とりあえず 逆引きRuby を Python で置き換えるとどうなるのか勉強してみた。pythontips's Wiki - FrontPage
鯨飲馬食 @ wiki - 逆引きPython があるから車輪の再発名でる。まあ 基本編 « python練習帳 などを眺めるほうが手っ取り早い。
2011-02-17 :-(
_ [NetBSD][翻訳][組み込み]BSD Newsletter: Building tiny systems with embedded NetBSD
組み込み向け小規模 NetBSD システムの構築
By Brian Rose
Overview (概要)
NetBSD is an extremely flexible operating system that is designed to be portable across various architectures. This feature makes it attractive for embedded developers. In this article, I will demonstrate a process for creating a very small kernel that can boot, either to a shell prompt or to a login screen.
NetBSD は様々なアーキテクチャに適用できるように設計されており、とても柔軟性に長けたオペレーティングシステムである。これにより組み込み開発者にはとても魅力的に映るのである。この文書では、とても小さいカーネルを作成し、ブートし、シェルプロンプトまたはログインスクリーンを表示するまでの作業過程を示す。
Booting to the shell prompt allows the developer to quickly give life to a system and perform some basic interactions. The shell itself can be a powerful management tool, combined with the right collection of programs. Doing this requires only the kernel and two binaries.
シェルプロンプトを起動できれば、開発者がシステムを手早く利用できるようなり、最低限の作業をおこなうことができるようになる。シェル身はとても強力な管理ツールで、いくつかのプログラムと組み合わせて使う。そのためにはカーネルと、2 つのバイナリーだけがあればよい。
Booting to a login prompt provides a little added security by controlling access to the machine. This would be useful in devices where the console can be accessed by the user, and you need to control what the user has access to. There are a few added files in this setup, and to keep things small, you will need to manually trim some of them. But this is still a very easy process.
ログインプロンプトは、計算機のアクセス制御のための仕組みをもたらす。通常、ユーザーはコンソールに接続されたデバイスからアクセスし、ユーザーがおこなえる範囲内で制御する。このセットアップでいくつかのファイルを追加し、小規模システムとするために多少の手作業が必要になる。でもほんとにほんの少しの作業である。
The minimum single user system (最小限のシングルユーザーシステム)
The first stage of embedded development usually involves getting a skeleton operating system up and running. Assuming you are using one of NetBSD many supported platforms, this is quite easy. I used a PC booting off of a floppy drive. But this method can also be easily adapted to handle diskless clients that boot off a network.
通常 組み込み開発の最初の段階はオペレーティングシステムを起動し、走らせるためのひな型を得ることだ。当然ながら多数のプラットフォームに対応した NetBSD のどれかのプラットフォームを使えばよろしい。じつに簡単だ。私はフロッピードライブから起動させるようにしている。ディスクレスクライアントでネットワークブートさせるように簡単に出来る。
At an absolute minimum, you will need the kernel, the /dev nodes for your system, and a /sbin/init file. You can craft the init program yourself, putting all of your application code into it. This may be a good solution when you only have one application that you would like to run.
最低でもカーネルと /dev と /sbin/init が必要だ。自分のアプリケーションを init として設置するのもよい。アプリケーション 1 つだけを走らせるならば、これは良い方法だ。
Another option is to use the stock init program and a shell to call your application. This is a bit easier than writing your own init program, and it also allows you to add functionality to your system by simply adding more tools from the stock system. The shell itself is a powerful tool that can make future development much easier. This is the method that will be illustrated here.
他に、init をストックしたり { ???? } シェルからあなたのアプリケーションを起動させるようにするのもアリだ。オレオレ init を書くよりは楽だし、ストックシステム { ???? } のツールから機能を追加することもできるようになる。シェルはとても強力なツールであり、開発作業をとても楽にすることができるだろう。図を参照。{ 図って???? }
Building the kernel (カーネルを構築する)
The first thing that needs to be done is to build a kernel with a built in ramdisk. The ramdisk will hold the kernel's root filesystem. A good kernel configuration to start with is the INSTALL_TINY configuration. This kernel has all the important stuff in it, without a lot of bloat. Make sure that it has the following lines in it.
最初にやることは、ramdisk 対応カーネルを構築することだ。ramdisk はカーネルの root ファイルシステムとして利用する。カーネルコンフィグファイル INSTALL_TINY が良い例になる。INSTALL_TINY カーネルは今回の作業に使うには充分だし、それほど肥大でもない。以下の行を追加する。
in sys/arch/[arch]/conf
sys/arch/[arch]/conf に移動して
$ cp INSTALL_TINY MYTINY $ vi MYTINY
# Enable the hooks used for initializing the root memory-disk. options MEMORY_DISK_HOOKS options MEMORY_DISK_IS_ROOT # force root on memory disk options MEMORY_DISK_SERVER=1 # make the ramdisk writeable #options MEMORY_DISK_ROOT_SIZE=2880 # 1.44M, same as a floppy options MEMORY_DISK_ROOT_SIZE=8192 # 4Meg options MEMORY_RBFLAGS=0 # don't force single user
This configuration includes ramdisk support, has the kernel boot from the ramdisk, allows the ramdisk to be written to, sets the size a 8192 sectors (512 bytes each), and allows the kernel to boot into multiuser mode (if the files are available).
この設定では、ramdisk に対応、ramdisk からのカーネル起動、ramdisk を書き込み可、8192 セクター (512 バイトごと) に設定、マルチユーザーモードで起動 (ファイル { どれ??? }が有効になっていれば) をおこなっている。
You will also need to check the ramdisk driver to make sure that it supports the MEMORY_RBFLAGS option. In my 1.6.0 system, it did not, so I needed to add the following code.
MEMORY_RBFLAGS オプションをつけて ramdisk ドライバ対応していることを確認すること。1.6.0 では対応してなかったので以下のコードを追加した。
in sys/dev/md_root.c
sys/dev/md_root.c を編集
/*
* This is called during open (i.e. mountroot)
*/
## #ifndef MEMORY_RBFLAGS
## #define MEMORY_RBFLAGS RB_SINGLE
## #endif
void
md_open_hook(int unit, struct md_conf *md)
{
// ............................... added code 追加したコード
if (unit == 0 && (MEMORY_RBFLAGS & RB_SINGLE) ) {
/* The root ramdisk only works single-user. */
boothowto |= RB_SINGLE;
}
}
Once this is done, build your kernel.
編集したらカーネルをビルドする。
$ config MYTINY $ cp ../compile/MYTINY $ make depend; make
Creating the crunched binaries (クランチバイナリを作成する)
Although you could copy the binaries from your host into your mini filesystem, a more efficient way (sizewise) to do this is to use a utility called crunchgen. Many programs in the NetBSD system are linked statically. For example, each program that uses the utility library (libutil) has one copy of the library linked to it. Several programs on the system produce redundant copies of the libraries used by the programs. Crunchgen takes the programs' object files and merges them into one uber-program. This crunched binary is then linked to the libraries, so only one copy of the library is needed for the whole system.
といっても、あなたの小規模ファイルシステムのホスト { 「ホスト内のファイルシステム」じゃないのか???? }からバイナリをコピーしてくればよい。crunchgen と呼ばれるツールを利用すると簡単に出来る。NetBSD システムの多くのプログラムは静的リンクされている。たとえば、各々独自にユーティリティライブラリ (libutil) を静的リンクしている。プログラムが利用しているライブラリのコピーを NetBSD ではいくつか提供している。Crunchgen はプログラムのオブジェクトファイルを抽出し、1 つのプログラムとしてマージする。クランチされたバイナリは上述のライブラリ群とリンクされるので、動作させたいシステムにライブラリをコピーするだけで使えるようになる。
"But how do I use the different programs?", you ask. The answer lies in hard links. A hard link is like a filesystem's alias for a program. For example, If I have a program called print_my_error, I can link that to the alias myerr. Then when I invoke myerr, the filesystem simply follows the link and runs the program print_my_error. I can even make the two program names have slightly different behavior. This is done by having print_my_error look at argv[0] that is passed to the main() function. If it is myerr, then I can have it do a special task.
「別のプログラムでも使いたいんだけど?」とあなたは言うだろう。ハードリンクにヒントがある。ハードリンクはファイルシステムでプログラムの別名のようなものだ。たとえば、print_my_error というプログラムがあるとしよう。それを myerr というハードリンクにしたとする。で、myerr を実行すると、ファイルシステムはリンクを辿り、print_my_error を呼び出す。2 つの名前をつけておくことにより、異なる振る舞いをさせることができる。print_my_error の main() 関数の argv[0] を見て振る舞いを変えればよい。myerr として呼ばれたら別の処理をさせる。
This is how crunchgen works. It takes all of its constituent programs and globs them together. Then in the crunched binary's main routine, there is logic that examines argv[0] and calls the main routine for the appropriate constituent.
これが crunchgen の仕組みである。crunchgen はプログラム群の塊を生成する。crunchgen されたバイナリは、main 関数で argv[0] を評価し、塊に含まれている適切なプログラムを呼び出すのである。
To make a crunched binary, you need to know what binaries you want, where their sources are located, and what libraries they use. Once you settle on what binaries to use, simply search the /usr/src folder for the sources. The layout of /usr/src is straightforward. To look for the source for /sbin/init, you would look in /usr/src/sbin/init. To find the /usr/bin/login, go to /usr/src/usr.bin/login. To find out which libraries are used, open up the program's Makefile, and look for the LDADD lines. You should see entries like "-lutil -lcrypt".
crunchgen されたバイナリを作成するには、どのバイナリを含めるのかを決め、そのソースの場所と、それらが使用するライブラリを把握する必要がある。バイナリを決めたら、/usr/src フォルダでソースを探してみよう。/usr/src 以下の配置は簡単だ。/sbin/init のソースを探すならば /usr/src/sbin/init にある。/usr/bin/login のソースは /usr/src/usr.bin/login にある。プログラムが利用しているライブラリを見つけるにはプログラムの Makefile を見よう。LDADD の行に "-lutil -lcrypt" などというふうに書いてあるはずだ。
Sometimes, programs in the NetBSD distribution are simply hardlinks to another program. For example, mount_mfs is an alias for newfs. You will find no /usr/src/sbin/mount_mfs directory. So how do you find out where the sources are for mount_mfs? Search through the makefiles for "LINKS= ${BINDIR}/newfs ${BINDIR}/mount_mfs". This shows you that the Makefile will link mount_mfs to newfs.
NetBSD の配布物ではあるプログラムが別のプログラムのハードリンクになっていることがある。たとえば mount_mfs は newfs の別名だ。/usr/src/sbin/mount_mfs というディレクトリは無いのである。では mount_mfs のソースはどこにあるのか? Makefile の "LINKS= ${BINDIR}/newfs ${BINDIR}/mount_mfs" に注目。mount_mfs は newfs へのリンクであることが分かる。
$ find /usr/src -name Makefile -exec grep mount_mfs {} \;
MAN= newfs.8 mount_mfs.8
LINKS= ${BINDIR}/newfs ${BINDIR}/mount_mfs
MLINKS= mount_mfs.8 mfs.8
Armed with this information, you can now create your crunchgen configuration file. This is just a list of the above information. There are some additional features, which I will outline below.
なお、crunchgen のための設定ファイルを作ることができる。といっても先ほど説明した内容をリストにするだけである。以下では多少の機能を追加してある。
srcdirs /usr/src/bin /usr/src/sbin progs init sh reboot ls ln sh -sh special init objpaths /usr/src/sbin/init/obj/init.smallprog.o # libraries used by the programs # ---------------- Minimum single user files # init : -lutil -lcrypt # sh : -ll -ledit -ltermcap # ---------------- Useful utilities # ls : - # reboot : -lutil # libs -lutil -lcrypt -ll -ledit -ltermcap
The first line tells crunchgen where to look for sources. It looks for the sources by appending the program name onto the listed directories. The progs line is the list of programs that you want included in your binary. The ln lines tell crunchgen about aliases that are used for some of the programs. The shell is sometimes invoked as -sh, so the crunched binary will recognize "-sh" as "sh". Also, as noted above, some binaries are simply aliases for other programs. The crunched binary needs to be on the lookout for these aliases as well.
最初の行は crunchgen がソースを探す場所を示している。このディレクトリにプログラム名を付加したディレクトリから探す。progs 行はバイナリに含めるプログラムを列挙する。crunchgen の別名とするプログラム名となる。シェルは -sh として実行されることがあるので "-sh" と "sh" と書けるのである。また、あるプログラムの別名となっているプログラムについても crunchgen は適切に別名を探してくれる。
The special line tells crunchgen that init should not be built from source, but rather just use the specified object file. In this case, I built the init program with the SMALLPROG #define, so I don't get the annoying "Enter pathname of shell or RETURN for sh:" prompt when the system starts in single user mode. Instead, it will silently drop to the shell prompt. To do this, I build my special init program this way.
special 行は crunchgen が init がソースからビルドされるわけではなく、オブジェクトファイルが使用されることを示している。今回は SMALLPROG を #define 定義してプログラムをビルドした。これにより、シングルユーザーモードでシステムが起動したときに "Enter pathname of shell or RETURN for sh:" という鬱陶しいアレを見ずに済む。その代わり、すぐにシェルプロンプトへ入る。これをやるために以下のように init プログラムに特殊な変更を施した。
$ cd /usr/src/sbin/init $ make -D SMALLPROG $ cp obj/init.o obj/init.smallprog.o
This functionality makes it easy to customize your system without too much trouble. You could create a customized version of a standard program and use that in your embedded builds, while keeping the original for other purposes.
こうすることでシステムへの悪影響を少なくしてカスタマイズできる。組み込みシステムで使うために標準的なプログラムをカスタマイズするならば、オリジナルは保存しておくように。
Finally, the last line tells crunchgen which libraries to link to. Again, you can get this information by looking through the Makefiles for the constituent programs and noting the LDADD lines. I've had trouble with library ordering, so if you have errors indicating unresolved externals, and you know you included the library, try moving the "missing" library closer to the front of the list. This worked for me.
最後の行は crunchgen がリンクするライブラリを示している。前述したとおり、どのライブラリが使われるのかという情報は、各プログラムの Makefile の LDADD 行に書いてある。私が作業したときはライブラリを探す順番でトラブルがあったのだが、もしあなたが未解決の外部参照エラーに見舞われた場合は、ライブラリの行からライブラリを外して試すとよい。私はそうした。
Once your crunchgen file is crafted, build it with the following commands. The finished executable will be named after your conf file, but without the conf extension.
これで crunchgen ファイルが使えるようになった。以下のコマンドを実行してビルドしよう。ビルドが完了すると、設定ファイルの .conf を省いた名前でバイナリが生成される。
$ crunchgen -m Makefile mytiny.conf $ make -f Makefile objs exe
_ [NetBSD][翻訳][組み込み]BSD Newsletter: Building tiny systems with embedded NetBSD (page 2)
組み込み向け小規模 NetBSD システムの構築(ページ2)
Creating the filesystem image (ファイルシステムイメージを作成する)
Now that our binaries are all wrapped up, the next thing to do is to populate the filesystem. This involves linking all the programs to the crunched binary and copying or creating the necessary data files. This is easily done with the following commands. Don't forget to set the permissions to root:wheel!
これでバイナリは準備できた。次はファイルシステムに取り掛かろう。これは全てのプログラムを crunche されたバイナリとしてリンクしたり、データファイルをコピー、作成することも含まれる。以下のコマンドを実行するだけの簡単な仕事だ。パーミッションを root:wheel に設定しておくこと。
$ mkdir files/bin files/sbin files/dev $ cp /dev/MAKEDEV files/dev $ cd files/dev $ ./MAKEDEV floppy ramdisk wscons $ cd ../.. $ cp work/mytiny files/sbin/init $ ln files/sbin/init files/bin/sh $ ln files/sbin/init files/bin/ls $ ln files/sbin/init files/sbin/reboot $ su root # chown -R root:wheel files # exit
With the filesystem populated, we can wrap it up into an image file that can be embedded into a kernel. This is done with the makefs command. This tool lets you take a directory and bundle it up into a single file. Make sure that your size is not larger than the size you specified in your kernel configuration. Once the image is created, link it to the kernel with the mdsetimage command. Your kernel is now ready to go!
ファイルシステムが準備できたらイメージファイルをカーネルに組み込もう。これは makefs コマンドを実行するだけだ。makefs はディレクトリを 1 つのイメージにまとめるツールだ。カーネルに設定したサイズ { カーネルサイズか } よりも大きくならないように注意すること。イメージが作成できたら mdsetimage コマンドでカーネルにリンクする。これでカーネルは準備完了だ。
You can compress your kernel if you like. The standard NetBSD bootloader knows how to decompress gzipped kernels. Remember, your spartan OS includes 4 megabytes of mostly empty space in the filesystem. I compressed my kernel down to 825,544 bytes.
必要であればカーネルを圧縮することができる。NetBSD 標準の bootloader は gzip されたカーネルに対応している。NetBSD のファイルシステムには 4MB の空き領域がある {????????????}。私はカーネルを 825,544 byte まで圧縮した。
# makefs -s 4m -t ffs crunch.image files # mdsetimage netbsd.ramdisk crunch.image # gzip -c netbsd.ramdisk > netbsd # ls -l netbsd -rw-r--rw- 1 brose users 825544 Aug 24 22:28 netbsd
When you boot this kernel, you will see the normal output and then it will present you with a shell prompt. At that time, you can do whatever it is you need to do. My example will let you move around the file structure, list the contents with ls, and reboot. Not very useful, but it is a good starting point.
カーネルがブートすると、見慣れた起動メッセージが表示されたあとに、シェルプロンプトが表示される。そうしたら、あなたはやりたいことをやれるようになる。ファイルシステムを歩いて中身を眺めたり、reboot するとよい。まあ一般的ではないけど第一歩としては悪くない。
The minimum multi user system (小規模マルチユーザーシステム)
A multi user system is built in the same manner, but you need a few extra programs and data files. I also use the standard init program. Notice that I commented out the special init line, so that I use the stock init for the multiuser configuration. You may want to go back to your init source and make a fresh init, just in case the .o files are from your single user build.
マルチユーザーシステムは、多少のプログラムとデータファイルを追加するだけで先ほどと同じように作成できる。今回も標準 init プログラムを使う。special 行の init をコメントアウトした。マルチユーザーの設定で使うためだ。.o ファイルがシングルユーザー用にビルドしたものなので、init のソースへ行って make しなおそう。
$ cd /usr/src/sbin/init $ make clean; make
Here's my crunchgen configuration.
crunchgen 設定ファイルはこう。
srcdirs /usr/src/bin /usr/src/sbin /usr/src/usr.bin /usr/src/usr.sbin /usr/src/libexec progs init mount newfs mount_ffs sh ttyflags getty pwd_mkdb passwd login reboot ls ln sh -sh ln newfs mount_mfs # special init objpaths /usr/src/sbin/init/init.smallprog.o # libraries used by the programs # ---------------- Minimum single user files # init : -lutil -lcrypt # mount : # newfs : -lutil # mount_ffs : # sh : -ll -ledit -ltermcap # ---------------- Minimum multiuser files # ttyflags : # getty : -lutil -ltermcap # pwd_mkdb : -lutil # passwd : -lrpcsvc -lcrypt -lutil -lkrb5 -lcrypto -lasn1 -lcom_err -lroken # login : -lutil -lcrypt -lskey -lkrb5 -lasn1 -lkrb -lcrypto -lroken -lcom_err # ---------------- Useful utilities # ls : # reboot : -lutil # umount : # libs -lutil -ll -ledit -ltermcap -lcrypt -lrpcsvc -lkrb5 -lkrb -lcrypto -lasn1 -lcom_err -lroken -lskey
And my shell commands for populating the filesystem.
ファイルシステムを作成するためのシェルコマンドはこう。
mkdir files/bin files/sbin files/usr files/etc files/var files/dev files/tmp files/root files/home mkdir files/usr/bin files/usr/sbin files/usr/libexec mkdir files/var/run files/var/db files/var/crash mkdir files/usr/share mkdir files/usr/share/misc cp /dev/MAKEDEV files/dev cd files/dev ./MAKEDEV floppy ramdisk wscons cd ../.. echo "/dev/md0a / ffs rw 1 1" > files/etc/fstab echo "echo Initializing system..." > files/etc/rc echo "export PATH=/sbin:/bin:/usr/sbin:/usr/bin" >> files/etc/rc echo "mount -ua" >> files/etc/rc echo "ttyflags -a" >> files/etc/rc cp work/mytiny files/sbin/init ln files/sbin/init files/bin/ls ln files/sbin/init files/sbin/mount ln files/sbin/init files/sbin/mount_ffs ln files/sbin/init files/sbin/mount_mfs ln files/sbin/init files/sbin/umount ln files/sbin/init files/bin/sh ln files/sbin/init files/usr/libexec/getty ln files/sbin/init files/sbin/ttyflags ln files/sbin/init files/sbin/pwd_mkdb ln files/sbin/init files/usr/bin/passwd ln files/sbin/init files/usr/bin/login ln files/sbin/init files/sbin/reboot ln files/sbin/init files/sbin/newfs cp /etc/ttys files/etc cp /etc/master.passwd files/etc cp /etc/pwd.db files/etc cp /etc/spwd.db files/etc cp /etc/passwd files/etc cp termcap.mini files/usr/share/misc/termcap cp /etc/gettytab files/etc
The termcap.mini file is simply a hand trimmed version of the termcap file. This is used by the getty program when initializing the console. Since it is very large (over 500k) and most of it is useless, you can trim out the terminal types that you don't use. I trimmed mine down to about 8k.
termcap.mini ファイルは termcap ファイルを仕分けしたものだ。これは getty プログラムがコンソールを初期化するときに使う。元は 500KB 以上あるのだが、ほとんどの設定は使わない。あなたも使用しないターミナル設定を削っておくとよい。私は 8KB まで削った。
Once you have done this, simply place this filesystem into a kernel and boot. As you can see, a multi user setup is a bit larger. But most of the extra space is from incorporating the extra libraries for the login and getty programs. As you add more code to the system, your code growth should not be as dramatic.
これが終わったらカーネルにファイルシステムを組み込んでブートしよう。マルチユーザーの設定なので大きくなっている。これは login と getty プログラムとそれらのライブラリを含めたためだ。さらにコードを追加したとしても、それほど劇的にサイズは大きくならないだろう。
# makefs -s 4m -t ffs crunch.image files # mdsetimage netbsd.ramdisk crunch.image # gzip -c netbsd.ramdisk > netbsd # ls -l netbsd -rw-r--rw- 1 brose users 1066057 Aug 24 22:28 netbsd
Brian Rose is an electrical engineer who has developed embedded software for the telecom and video distribution industries. He is currently on involuntary hiatus (layoff) and pondering the benefits of being a scuba instructor at Mexican resorts.
Brian Rose は通信機器やビデオ配信機器の組み込みソフトウェアを開発している電気技術者である。彼はいま一時休業中であり、メキシコのリゾート地でスキューバのインストラクターをしている。
Copyright (C) 2003 by Brian Rose, all rights reserved. Reproduced by BSD Newsletter.com with permission of the author.
RELATED INFO
2011-02-18 :-(
_ 夜
1800 武蔵小杉 || ベッカーズでコーヒー
1930 id:youichi と合流 || 日曜日対策会議 in ケンタッキーフライドチキン
2100 帰宅
2200 飯。厚切り豚バラの照り焼き
2011-02-19 :-)
_ [リッジレーサー7]リッジレーサー7 ARC 2010 如月GP
けやきん復帰レース
- SOLARE 139
- Locus 132
- リインフォース 104
- agumon11 99
- CONTI4X 95
- ANSΩmiwarin 78
- すたちき 73
- ANSΩB2マンタレイ 71
- ANSΩ三嶋出雲 68
- ANSΩkeyaki 51
- MEDAL 49
- かず 39
- ANSΩO.RYO 25
- ANSΩ限無 4
回線が酷いうえに運営をミスってしまった。すんません....
今回はリインフォースさんが速かったなあ。SOLARE さんが速いのは分かってるんだが。
- 走行距離 97656 km
- RSGP 進行度 100.0 %
- 名声 26287 FP
- オンラインバトル勝利数 1161/4141
2011-02-20 :-)
_ 午前
0600 起床。現場の id:youichi からグッズ物販列の連絡を貰うなど。総合すると徹夜組が居たらしい
0630 二度寝
0900 起床
1000 物販開始が 9 時なのでそろそろ買い終わるだろうと思っていたんだがまったく id:youichi から連絡が来ない。どうしたことか
1130 id:youichi から入電。いま買い終えたとのこと。お疲れ様です
_ [けいおん!!]TVアニメ「けいおん!!」ライブイベント ～Come with Me!!～
＠さいたまスーパーアリーナ
id:youichi の後輩が都合つかなくなったなどということで余ったチケットを貰って行ってきた。ありがとうゴマス
第 2 期 OP, ED とキャラソン全部とアンコールで第 1 期 OP, ED など。曲リストはダレかがどこかに書いてくれるに違いない。
U&I の歌詞をあらためてこうして聞いてみると唯たちの最後の文化祭を思い出して泣けてくるものだ。
調子に乗って跳び過ぎて脚腰が痛い。
- 豊崎愛生の脚がよかった
- 竹達彩奈の乳が揺れていてよかった
- サイリウムは要らないつもりだったんだが結局 id:youichi が持ってたのを 20 本くらい折った。すんません
- あとこれ けいおん!! 劇場版アニメは12月3日公開
とりあえず Utauyo MIRACLE でぐるぐる回れたので満足
2011-02-21 :-(
_ 価値
先日ブックオフにファミコン本体(初期じゃないアレ)、PS2(型番忘れた)、そして本をいくつか(学生のころ買った)売りに行ったんだが結局値段がついたのは PS2 の 600 円だけだった。岩波情報科学辞典は重要あるなら amazon で出品してもよかったか。
B0000648TM
4000800744
4000103555
4477016611
_ [NetBSD][翻訳][クロス開発]Cross-development with NetBSD
NetBSD でのクロス開発
Cross-Development with NetBSD Using NetBSD's new toolchain to develop for an embedded device
NetBSD の新しいツールチェインを使って組み込み機器をクロス開発する
Hubert Feyrer <hubert@feyrer.de>, October 2002
Introduction (はじめに)
When targeting a product for an embedded platform, it's not feasible to have all the development tools available on that same platform. Instead, some method of crosscompiling is usually used today. NetBSD 1.6 will contain (and NetBSD-current has today) a new framework to build both the operating system's kernel and the whole userland for either the same platform that the compiler runs on, or for a different platform, using crosscompiling. Crosscompiling requires assembler, linker, compiler etc. to be available and built for the target platform. The new build scheme will take care of creating these tools for a given platform, and make them available ready to use to do development work.
組み込み製品を開発するとき、同じプラットフォーム上ですべての開発ツールは利用できない。その代わり、最近はクロスコンパイル手法がよく使われる。NetBSD 1.6 ( と今の NetBSD-current ) には、同じプラットフォームでも異なるプラットフォームでもカーネルとユーザーランドをクロスコンパイルできるフレームワークがある。クロスコンパイルアセンブラ、リンカ、コンパイラなどを必要とする。これををターゲットのプラットフォーム向けに利用できるようにし、構築しておく。新しいビルドスキームはこうしたツールをターゲット向けに作成することができ、開発作業で使うために構築することができる。
Grabbing sources (ソースを取得する)
As an example, we will examine how to make a kernel for a Shark (StrongARM based system) from a machine running NetBSD/i386 in this article. The only requirement is that there is a fresh source tree of NetBSD-current checked out from CVS. "Fresh" here means that there should be no stale object files etc. in the tree - these can really get in the way here! The following commands can be used to get a copy of the -current branch checked out in /usr/cvs/src-current:
例として、ここでは NetBSD/i386 上で Shark (StrongARM based system) 向けのカーネルを構築してみよう。やり方は簡単だ。「最新」の NetBSD-current のソースツリーを CVS から取得すればよい。「最新」とは、安定していないといったことを意味する。ツリーはいまここで取得できるのさ。マジで。以下のコマンドは、-current ブランチをチェックアウトし、/usr/cvs/src-current にコピーする。
# mkdir /usr/cvs # cd /usr/cvs # env CVS_RSH=ssh cvs -d anoncvs@anoncvs.netbsd.org:/cvsroot co src # mv src src-current
The process of crosscompiling a kernel consists of three steps, which we will describe in more detail below:
カーネルをクロスコンパイルするには 3 つの手順がある。以降で詳細を説明する。
1. Create toolchain for crosscompiling (compiler, assembler, linker, ...)
2. Configure kernel
3. Build
1. クロスコンパイルのためのツールチェイン( コンパイラ、アセンブラ、リンカ...)を作成する
2. カーネルを設定する
3. 構築する
Creating the Crosscompiler (クロスコンパイラを作成する)
The first step to do cross-development is to get all the necessary tools available. In NetBSD terminology, this is called the "toolchain", and it includes BSD-compatible make(1), C/C++ compilers, linker, assembler, config(8), as well as a fair number of tools that are only required when crosscompiling a full NetBSD release, which we won't cover here.
クロス開発の最初の手順は必要なツールを揃えることだ。ツールは、NetBSD では "toolchain" と呼ばれており、それには BSD 互換 make(1)、C/C++ コンパイラ、リンカ、アセンブラ、config(8) が含まれている。あと、NetBSD を完全にリリースするためだけにいくつかツールがあるのだが、ここでは割愛する。
The command to create the toolchain is quite simple, using NetBSD's new src/build.sh script:
toolchain を作成するコマンドはいたって簡単だ。NetBSD の src/build.sh スクリプトを使えばよい。
# cd /usr/cvs/src-current # ./build.sh -m shark -u -t
This will build all the tools for the named target platform. Arguments used here are:
これで、指定されたターゲットプラットフォーム向けのツールを構築する。引数の意味はこう。
- -m: define the machine, MACHINE
- -u: update - only build files that have changed since last build
- -t: only build the toolchain (i.e. the crosscompiler!)
- -m: MACHINE として machine を定義する
- -u: アップデートする。最後にビルドしてから変更があったファイルだけをビルドする
- -t: toolchain だけをビルドする。( たとえばクロスコンパイラだ! )
During the build, object directories are used consistently, i.e. special directories are kept that keep the platform-specific object files and compile results. In our example, they will be kept in directories named "obj.shark" as we build for a Shark as target platform.
ビルド中はオブジェクトファイルが決められたディレクトリに作成される。たとえば、プラットフォーム独自のオブジェクトファイルとコンパイル結果が特殊なディレクトリに格納される。ここでは、Shark プラットフォーム向けのビルドなので "obj.shark" という名前のディレクトリが作成される。
The toolchain itself is part of this, but as it's hosted and compiled for a i386 system, it will get placed in it's own directory indicating where to cross-build from. Here's where our crosscompiler tools are located:
toolchain もこの中に入っているのだが、i386 上で i386 向けにコンパイルされたものも入っている。クロスビルドに使うための toolchain は独自のディレクトリに入っている。我々のクロスコンパイラツールは以下にある。
miyu# pwd /usr/cvs/src-current miyu# ls tools/obj.shark/ tools.NetBSD-1.6-i386
So the general rule of thumb is for a given "host" and "target" system combination, the crosscompiler will be placed in the "src/tools/obj.target/tools.host" directory by default. A full list of all tools created for crosscompiling the whole NetBSD operating system includes:
そして、通常は "host" と "target" の組み合わせが使われ、クロスコンパイラはデフォルトでは "src/tools/obj.target/tools.host" ディレクトリに配置される。NetBSD で作成されたクロスコンパイルツールの全リストはこう。
miyu# ls tools/obj.shark/tools.NetBSD-1.6-i386/bin/ arm--netbsdelf-addr2line arm--netbsdelf-strings nbmakefs arm--netbsdelf-ar arm--netbsdelf-strip nbmakeinfo arm--netbsdelf-as nbasn1_compile nbmakewhatis arm--netbsdelf-c++ nbcap_mkdb nbmenuc arm--netbsdelf-c++filt nbcompile_et nbmkdep arm--netbsdelf-cpp nbconfig nbmklocale arm--netbsdelf-dbsym nbcrunchgen nbmsgc arm--netbsdelf-g++ nbctags nbmtree arm--netbsdelf-g77 nbeqn nbpax arm--netbsdelf-gasp nbgencat nbpic arm--netbsdelf-gcc nbgroff nbpwd_mkdb arm--netbsdelf-gcov nbhost-mkdep nbrefer arm--netbsdelf-ld nbindxbib nbrpcgen arm--netbsdelf-lint nbinfo nbsoelim arm--netbsdelf-mdsetimage nbinstall nbtbl arm--netbsdelf-nm nbinstall-info nbtexi2dvi arm--netbsdelf-objcopy nblex nbtexindex arm--netbsdelf-objdump nblorder nbtsort arm--netbsdelf-ranlib nbm4 nbuudecode arm--netbsdelf-readelf nbmake nbyacc arm--netbsdelf-size nbmake-shark nbzic
As you can see, most of the tools that are available natively on NetBSD are also available, with some program prefix to identify the target platform. (The naming here is a bit redundant due to the directory structure containing all the information, but the program names are created by the GNU based toolchain and were chosen not to be changed).
このように、ネイティブの NetBSD 上で使えるほとんどのツールが使えるようになっている。ターゲットプラットフォームの接頭字がついているプログラムがいくつかある。(ディレクトリ名で区別できるのでこの命名は冗長なのだが、これらは GNU ベースの toolchain で作成されたので名前を変更できないのである)
One important tool that should be pointed out here is "nbmake-shark". This is a shell wrapper for a BSD compatible make(1) command that's setup to use all the right commands from the crosscompiler toolchain. Using this wrapper instead of /usr/bin/make allows crosscompiling programs that were written using the NetBSD Makefile infrastructure (see src/share/mk). We will use this make(1) wrapper in a second!
"nbmake-shark" に注目。これが重要なツールだ。これは BSD 互換 make(1) をシェルでラップし、クロスコンパイラ toolchain のすべてのコマンドを設定するのに使う。NetBSD Makefile ( src/share/mk参照 ) と同じように書けば /usr/bin/make の代わりとしてクロスコンパイルプログラムを使うことができる。これでもう make(1) を使えるのさ!
Configuring the kernel (カーネルを設定する)
Now that we have a working crosscompiler available, the "usual" steps for building a kernel are needed - config, then build. As the config(8) program used to create header files and Makefile for a kernel build is platform specific, we need to use the "nbconfig" program that's part of our new toolchain. That aside, the procedure is just as like compiling a "native" NetBSD kernel. Commands involved here are:
すでにクロスコンパイラが使えるようになっている。カーネルをビルドする「通常の」手順では config をしてからビルドをする。config(8) プログラムは、プラットフォーム独自のカーネルをビルドするためのヘッダーファイルと Makefile を作成する。そのために "nbconfig" を使う。これは新しい toolchain に含まれているプログラムだ。ネイティブな NetBSD カーネルをコンパイルするのと同じ手順で出来るのである。コマンドはこう。
# cd /usr/cvs/src-current/sys/arch/shark/conf/ # /usr/cvs/src-current/tools/obj.shark/tools.NetBSD-1.6-i386/bin/nbconfig GENERIC
That's all. This command has created a directory "../compile/GENERIC" with a number of header files defining information about devices to compile into the kernel, a Makefile that is setup to build all the needed files for the kernel, and link them together. As the Shark port uses ELF as execution format but the Shark's OpenFirmware can only load a.out kernels, that Makefile will also convert the kernel from ELF to a.out once it's built.
以上。このコマンドは "../compile/GENERIC" ディレクトリを作成し、カーネルでデバイスを使うための情報を定義したいくつかのヘッダーファイルを格納する。Makefile にはカーネルが必要とする全てのファイルを作成、リンクする。Shark ポートは実行形式として ELF を使うのだが、Shark の OpenFirmware は a.out 形式のカーネルしかロードできない。Makefile ではカーネルを ELF から a.out 形式へ変換する。
More information about building NetBSD kernels can be found at http://www.netbsd.org/Documentation/kernel/.
NetBSD カーネルのビルドの詳細は http://www.netbsd.org/Documentation/kernel/ を参照。
Crosscompiling the kernel (カーネルをクロスコンパイルする)
We have all the files and tools available to crosscompile our ARM-based kernel from our Intel-based host system, so let's get to it! After changing in the directory created in the previous step, we need to use the crosscompiler toolchain's "nbmake-shark" shell wrapper, which just calls make(1) with all the necessary settings for crosscompiling for a shark:
これで Intel ベースのホストシステム上で ARM ベースのカーネルをクロスコンパイルするためのファイルやツールが全て揃った。あとはやるだけだ。先の手順で作成されたディレクトリへ移動しよう。クロスコンパイラ toolchain のシェルラッパー "nbmake-shark" がある。shark のクロスコンパイルに必要な設定をおこない、make(1) を呼び出すだけだ。
# cd ../compile/GENERIC/ # /usr/cvs/src-current/tools/obj.shark/tools.NetBSD-1.6-i386/bin/nbmake-shark
This will churn away a bit, then spit out a kernel:
いくつか印字し、カーネルを出力する。
... text data bss dec hex filename 1687520 69632 184576 1941728 1da0e0 netbsd.aout miyu# ls -la netbsd.aout -rwxr-xr-x 1 root wheel 1757216 Mar 27 02:55 netbsd.aout miyu# file netbsd.aout netbsd.aout: NetBSD/arm32 demand paged executable
Now the a.out(!) kernel can either be transferred to a shark (via NFS, FTP, scp, etc.) and booted from a possible harddisk, or directly from our cross-development machine using NFS. Be sure to actually use the a.out kernel, as the Shark's firmware cannot use the one in ELF format.
これで a.out カーネルを shark へ転送し( NFS、FTP、scp などで ) ハードディスクから起動したり、クロス開発用マシンから NFS で直接起動させることができる。Shark のファームウェアは ELF 形式を扱えないので a.out カーネルを使うこと。
Crosscompiling the whole Operating System (オペレーティングシステム全体をクロスコンパイルする)
Of course you can not only crosscompile the NetBSD kernel, but the whole system. This is as easy as:
もちろん NetBSD カーネルだけをクロスコンパイルできるわけじゃない。システム全体をクロスコンパイルできる。以下のように簡単だ。
$ ./build.sh -m shark -d \
-D /usr/tmp/shark-root \
-R /usr/tmp/shark-release
This command will first build a crosscompiler, as described above. After that it will crosscompile the whole operating system including all libraries, binaries, etc. To make things complete, kernels for installing and running the systems will be built, and everything will be packed into distribution sets & install media, so a full NetBSD release is available i /usr/tmp/shark-release after that command!
このコマンドは、先ほど述べたように最初にクロスコンパイラをビルドする。それからライブラリ、バイナリなどを含めたシステム全体をクロスコンパイルする。完了したら、カーネルをインストールし、システムを走らせるために、sets とインストールメディアに圧縮する。そして /usr/tmp/shark-release を実行すれば NetBSD のフルリリースが出来上がるのさ!
Too easy? Sorry, but that's NetBSD! :-)
NetBSD なら簡単でしょ? :-)
Summary (まとめ)
So much for our small example on how to use the new build framework to do cross development of a kernel for and with NetBSD. Let me re-emphasize at this point again that the toolchain produced in the first step is capable of (re)building the complete NetBSD operating system including libraries and programs, not only the kernel. More information on building the whole operating system can be found in src/BUILDING. More documentation is also available as src/tools/compat/README, which has special emphasize on setting up crosscompiling from various host operating systems, i.e. Solaris and Linux besides NetBSD.
ここでは少しの例で NetBSD 上で NetBSD カーネルをクロス開発するためのビルドフレームワークの使い方を示した。最初の手順で使った toolchain をおさらいしておくと、toolchain は NetBSD カーネルだけでなくライブラリやプログラムを含めた NetBSD オペレーティングシステム全体の構築(再構築も)に使う。オペレーティングシステム全体の構築についてのもっと詳しい情報は src/BUILDING にある。NetBSD だけでなく Solaris や Linux など様々なホストオペレーティングシステム上でのクロスコンパイルについての文書は src/tools/compat/README にある。
(c) Copyright 20020110 Hubert Feyrer <hubert@feyrer.de>
$Id: xdev.html,v 1.6 2002/10/15 23:46:15 feyrer Exp $
2011-02-22 :-(
2011-02-24 :-(
_ 午後
1300 sleep
_ [DNS][BIND][NetBSD][翻訳]DNS and BIND on NetBSD
NetBSD での DNS と BIND
DNS and BIND on NetBSD
by Hoang Q. Tran
Three advices:
助言が 3 つある
1. Get DNS and BIND book. It's nice to understand how DNS works.
2. DNS needs time to distribute its information.
3. BIND won't load if there is a syntax error.
- DNS and BIND 本を入手せよ。DNS の仕組みを理解するにはよい
- DNS は情報を配布するには時間がかかる
- BIND は{ 設定ファイルを }ロードするときにシンタックスエラーを報告しない
If you have two or more computers, it is recommended to use DNS instead of /etc/hosts. Another obvious advantage is mail routing. With traditional /etc/hosts, there is no easy way to specify backup mail servers for mail delivery. This howto is based on the author's experience with BIND on his favourite NetBSD 1.5.1 and 1.5X boxes.
あなたがもし 2 つかそれ以上のコンピュータを持っているならば、/etc/hosts よりも DNS を使うことをお勧めする。メールルーティングにも優位だ。伝統的な /etc/hosts では、メール配送のためのメールサーバーたちのバックアップを作るのは容易ではない。ここでは、筆者の環境で NetBSD 1.5.1 と 1.5X 系計算機で BIND を使った経験を記す。
- Download BIND
- Setup zone and DNS records
- Secure BIND
- Different DNS servers
- Run DNS for your own domain
- Familiarize with DNS tools
- Reference
- BIND をダウンロードする
- zone と DNS レコードを設定する
- BIND をセキュアにする
- DNS サーバー群の相違
- DNS を自分のドメインで走らせる
- DNS ツールに慣れる
- 参考
Download BIND (BIND をダウンロードする)
NetBSD 1.5.1 comes with BIND 8.2.3 and 8.2.4-REL-NOESW on NetBSD 1.5X. BIND8 is considered to be stable and is used by most root name servers. BIND9 is a complete rewrite with several new features:
NetBSD 1.5.1 では NetBSD 1.5X 用の BIND 8.2.3 と 8.2.4-REL-NOESW が使えるようになった。BIND8 は安定しており、ほとんどのルートネームサーバーで使われている。BIND9 はいくつか実装を書き直したものだ。
DNSSEC (signed zones) TSIG (signed DNS requests) IPv6 support Bitstring Labels DNS Protocol Enhancements IXFR, DDNS, Notify, EDNS0 Views (former split-dns) Multiprocessor Support Improved Portability Architecture
So it is worthwhile to run and play with new features. For the rest of the howto, BIND means BIND version 9.
これらは実際に走らせてみるだけの価値がある機能である。この文書では、 BIND は BIND バージョン 9 を指す。
Since BIND is in the NetBSD packages collection, first, get the packages collection then install BIND. You can skip this part and just download the BIND source from here and just build yourself.
BIND は NetBSD パッケージコレクションに含まれているので、まずはパッケージコレクションを所得し、それから BIND をインストールする。BIND のソースをダウンロードしてビルドするだけならばこの部分は読み飛ばしてよい。
Edit an example supfile in /usr/share/examples/supfiles:
/usr/share/examples/supfiles にある supfile のサンプルを編集する。
# cp /usr/share/examples/supfiles/sup.netbsd.org /etc/ports-supfile
Remove other lines except for the ``current release'' below.
current release の行 以外を削除する。
# $NetBSD: sup.netbsd.org,v 1.4.10.1 2000/08/10 23:15:24 soda Exp $ # # Example supfile for sup.netbsd.org. # current release=pkgsrc host=sup.netbsd.org hostbase=/ftp/pub \ base=/usr prefix=/usr backup use-rel-suffix compress delete
Retrieve the packages collection:
パッケージコレクションを取得。
# cd /usr # sup /etc/ports-supfile ( packages downloading, it will take a while. Maybe now is a good time for an expresso cup... ) ...
Once it is done, build and install BIND9 as:
終わったら BIND9 をビルドしてインストールする。
# cd /usr/pkgsrc/net/BIND9 # make install clean ( BIND9 building, installing and cleaning...Another expresso cup would be nice ) ...
BIND binaries will be installed mostly in /usr/pkg/sbin. It also comes with lwresd and named9 scripts in /usr/pkg/etc/rc.d. Copy named9 to /etc/rc.d and turn on the executable bit with chmod +x.
BIND のバイナリはたいてい /usr/pkg/sbin にインストールされる。lwresd と named9 のスクリプトが /usr/pkg/etc/rc.d に格納される。named9 を /etc/rc.d にコピーし、chmod +x して実行ビットを立てる。
# cp /usr/pkg/etc/rc.d/named9 /etc/rc.d # chmod +x /etc/rc.d/named9
lwresd is the lightweight resident daemon. Not a requirement to get BIND running. Now, enable BIND on startup:
lwresd はライトウェイトの軽量デーモンであり、BIND とは別に動作する。{ システムの } 起動時に BIND を有効にさせる。
# vi /etc/rc.conf.d/named9 and add:
named9=YES named_flags="-c /etc/namedb/named.conf"
This will start BIND as root user in non-chroot compartment. Section 3 of this howto will change how it runs.
これで root ユーザーとして BIND が起動するようになるのだが、chroot 環境ではない。それについてはセクション 3 で扱う。
Setup zone and DNS records (zone と DNS レコードを設定する)
For this howto, assume the following ficticious information:
ここでは架空の環境を設定する。
Domain example.com: (example.com ドメイン)
host1:
IP: 10.0.0.1
Purpose: primary DNS server
primary mail server
primary web server
host2:
IP: 10.0.0.2
Purpose: secondary DNS server
secondary mail server
host3:
IP: 10.0.0.3
Purpose: secondary DNS server
primary ftp server
network: 10.0.0/24
loopback: 127.0.0.1
BIND configuration files for host1 as primary DNS server: (プライマリ DNS サーバーとして host1 を設定する)
Configuration directory (設定ディレクトリ): /etc/namedb
Main configuration file (メイン設定ファイル): named.conf
example.com name-to-address zone (正引きゾーンファイル): db.example
example.com address-to-name zone (逆引きゾーンファイル): db.10.0.0
loopback zone (ループバック): db.127.0.0
root hint zone (ルートヒント): db.cache
/*
* Main configuration file
* /etc/namedb/named.conf
*/
/* Global options */
options {
/* BIND directory */
directory "/etc/namedb";
auth-nxdomain no;
};
/* Local network name-to-address zone file */
zone "example.com" in {
/* This zone is of type primary and will load the zone file
* from local disk.
*/
type master;
file "db.example";
};
/* Local network reverse map zone file */
zone "0.0.10.IN-ADDR.ARPA" in {
/* This zone is of type primary and will load the zone file
* from local disk.
*/
type master;
file "db.10.0.0";
};
/* Loopback reverse map zone file */
zone "0.0.127.IN-ADDR.ARPA" in {
/* This zone is of type primary and will load the zone file
* from local disk.
*/
type master;
file "db.127.0.0";
};
/* Use root servers for non-authoritative domains */
zone "." in {
/* Consult root servers for other domains. */
type hint;
file "db.cache";
};
/*
* example.com name-to-address zone
* /etc/namedb/db.example
*/
$TTL 86400
@ IN SOA host1.example.com. hostmaster.example.com. (
2001081101 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ; minimum negative cache TTL of 1 day
)
;
; Name servers
;
IN NS host1.example.com.
IN NS host2.example.com.
IN NS host3.example.com.
;
; Mail MX RRs
;
example.com. IN MX 0 host1.example.com.
IN MX 10 host2.example.com.
;
; Addresses for the canonical names
;
localhost IN A 127.0.0.1
host1 IN A 10.0.0.1
host2 IN A 10.0.0.2
host3 IN A 10.0.0.3
;
; Aliases
;
www IN CNAME host1.example.com.
mail IN CNAME host2.example.com.
ftp IN CNAME host3.example.com.
/*
* example.com address-to-name zone
* /etc/namedb/db.10.0.0
*/
$TTL 86400
@ IN SOA host1.example.com. hostmaster.example.com. (
2001081101 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ; minimum negative cache TTL of 1 day
)
;
; Name servers
;
IN NS host1.example.com.
IN NS host2.example.com.
IN NS host3.example.com.
;
; Addresses point to canonical name
;
1 IN PTR host1.example.com.
2 IN PTR host2.example.com.
3 IN PTR host3.example.com.
/*
* example.com loopback zone
* /etc/namedb/db.127.0.0
*/
$TTL 86400
@ IN SOA host1.example.com. hostmaster.example.com. (
2001081101 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ; minimum negative cache TTL of 1 day
)
;
; Name servers
;
IN NS host1.example.com.
IN NS host2.example.com.
IN NS host3.example.com.
1.0.0.127.IN-ADDR.ARPA. IN PTR localhost.
For root hint zone, either rename root.hint to db.cache or execute this command to download the latest copy.
ルートヒントゾーンのために root.hint を db.cache に名前変更するか、または以下のコマンドを実行して最新のコピーをダウンロードする。
# dig @a.root-servers.net. . ns > /etc/namedb/db.cache
BIND configuration files for host2 as secondary: (セカンダリとして host2 を設定する)
Configuration directory (設定ディレクトリ): /etc/namedb
Main configuration file (メイン設定ファイル): named.conf
example.com name-to-address zone (正引きゾーンファイル): secondary for host1
example.com address-to-name zone (逆引きゾーンファイル): secondary for host1
loopback zone (ループバック): db.127.0.0
root hint zone (ルートヒント): db.cache
/*
* BIND configuration file for host2
* /etc/namedb/named.conf
*/
/* Global options */
options {
/* BIND directory */
directory "/etc/namedb";
auth-nxdomain no;
};
/* Local network name to address zone file */
zone "example.com" in {
/* This zone is of type secondary and will download the zone file
* from host1.
*/
type slave;
file "db.example";
masters { 10.0.0.1; };
};
/* Local network reverse map zone file */
zone "0.0.10.IN-ADDR.ARPA" in {
/* This zone is of type secondary and will download the zone file
* from host1.
*/
type slave;
file "db.10.0.0";
masters { 10.0.0.1; };
};
/* Loopback reverse map zone file */
zone "0.0.127.IN-ADDR.ARPA" in {
/* This zone is of type primary and will load the zone file from
* local disk.
*/
type master;
file "db.127.0.0";
};
/* Use root servers for non-authoritative domains */
zone "." in {
/* Consult root servers for other domains. */
type hint;
file "db.cache";
};
/*
* example.com loopback zone
* /etc/namedb/db.127.0.0
*/
$TTL 86400
@ IN SOA host1.example.com. hostmaster.example.com. (
2001081101 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ; minimum negative cache TTL of 1 day
)
;
; Name servers
;
IN NS host1.example.com.
IN NS host2.example.com.
IN NS host3.example.com.
1.0.0.127.IN-ADDR.ARPA. IN PTR localhost.
For root hint zone, either rename root.hint to db.cache or execute this command to download the latest copy.
ルートヒントゾーンのために root.hint を db.cache に名前変更するか、または以下のコマンドを実行して最新のコピーをダウンロードする。
# dig @a.root-servers.net. . ns > /etc/namedb/db.cache
BIND configuration files for host3 as slave: (スレーブとして host3 を設定する)
Configuration directory (設定ディレクトリ): /etc/namedb
Main configuration file (メイン設定ファイル): named.conf
example.com name-to-address zone (正引きゾーンファイル): secondary for host1
example.com address-to-name zone (逆引きゾーンファイル): secondary for host1
loopback zone (ループバック): db.127.0.0
root hint zone (ルートヒント): db.cache
From this point on, host3 configuration files are identical to host2. Just repeat the steps for host2.
host3 の設定ファイルは host2 と同じなので host2 の手続きを繰り返す。
Starting BIND: (BIND を起動する)
Before starting BIND on host1, verify that named.conf and zone files are syntatically correct and valid.
host1 で BIND を起動する前に、named.conf とゾーンファイルの構文が正しいかチェックする。
# /usr/pkg/sbin/named-checkconf /etc/namedb/named.conf # /usr/pkg/sbin/named-checkzone example.com /etc/namedb/db.example
At this point, BIND is ready to start:
これで BIND の起動準備ができた。
# /etc/rc.d/named9 start Starting named. #
Check /var/log/messages for the last line for the word "running". e.g.: Aug 6 16:01:00 roseapple /usr/pkg/sbin/named[8203]: running
/var/log/messages に "running" という行があることを確認する。例: Aug 6 16:01:00 roseapple /usr/pkg/sbin/named[8203]: running
Looks like BIND is running on host1. Repeat this step for host2 and host3.
host1 で BIND が起動したら、host2 と host3 でも同様に作業する。
Once all three hosts are up and running, lets put them into use by editing /etc/resolv.conf and add:
3 つのホストで BIND が起動したら、それらのホストの /etc/resolv.conf に以下を追加する。
search example.com nameserver 10.0.0.1 nameserver 10.0.0.2 nameserver 10.0.0.3
Then ping host2, host3 and localhost from host1 to see if name-to-address is working. They should resolve to 10.0.0.2, 10.0.0.3 and 127.0.0.1. Try to ping www.yahoo.com to see if BIND is perusing root hint zone. Finally, to test reverse mapping, use ``host'' and give the IP address of host2, 3 and localhost and the output should look similar to this:
host1 から host2 と host3 と localhost へ向けて ping を打つ。正引き出来ていれば ping が通る。各々 10.0.0.2、10.0.0.3、127.0.0.1 として名前解決されるはずだ。BIND がちゃんとルートヒントゾーンを読んでるか確認するために www.yahoo.com へ ping する。最後に reverse mapping しているか確認するために host コマンドで host2、host3、localhost の IP アドレスが取得でき、以下のように印字されることを確認する。
# host 10.0.0.2 2.0.0.10.IN-ADDR.ARPA domain name pointer host2.example.com
Repeat this on host2 and host3. Both should behave the same as host1. If all goes well, time for a third expresso cup. It is definitely boring doing all these steps. There is a utility called h2n which will convert a working /etc/hosts into configuration files above. However, doing manually is tedious but sure makes your brain smarter.
以上の作業を host2 と host3 で繰り返す。host1 と同じ結果になるはずだ。全てうまくいったらティータイムにしよう。けっこうしんどい作業だからね。これまでの設定ファイルを /etc/hosts へ変換するための h2n というユーティリティがあるので、手作業に飽きたら使ってみるとよい。
Secure BIND (BIND をセキュアにする)
Now that everything is working, there are other considerations to make it more secure.
これで全て動作はしている。もっとセキュアにしてみよう。
Early versions of BIND did not have a good security record. However, BIND is still the best implementation around.
BIND の以前のバージョンはあまり security record ではなかった。{ ググったら「保障記録」と言われたけど何のことだ???? } しかし、もはや BIND は最良の実装になっている。
Obscure BIND version: (BIND のバージョンを隠ぺいする)
Firstly, people have no business in knowing what version of BIND is running. Secondly, according to the Project Honeynet, the two most popular scans from script kiddies on the internet today are BIND version and portmap (rpcbind). So this is another good reason to not give them the easy information they need.
第一に、仕事では BIND のバージョンを気にしているひとは居ない。第二に、ハニーネット { ref. ハニーポット - Wikipedia } によれば、スクリプトキディによる代表的なスキャン方式は 2 つあって、BIND のバージョンチェックと portmap (rpcbind) のチェックだ。よって、連中に余計な情報を与えないようにするには、別の情報を返してやればよい。
In /etc/namedb/named.conf, add a version statement and put whatever you want between double quote.
/etc/namedb/named.conf にバージョンの文を追加し、ダブルクォートでくくる。
options {
directory "/etc/namedb";
version "Expresso cup";
};
Now, use dig to query the version from a remote host and "Expresso cup" should appear instead of real BIND version.
リモートホストから dig を実行すると、本物の BIND バージョンの代わりに "Expresso cup" というバージョンが返ってくる。
# dig @host1.example.com txt chaos version.bind
Restrict zone transfer: (ゾーン転送を制限する)
Zone transfer is intended for secondary nameservers to retrieve any zones for backup purposes. For other nameservers, they should not be able to retrieve any zones and use whatever information to mount attacks. Lets restrict zone transfer to trusted secondary nameservers only.
ゾーン転送は、ゾーン検索のバックアップをセカンダリネームサーバーに任せることである。他のネームサーバーはゾーンを検索させないし、させたらフルボッコされる {mount attacks}。ゾーン転送を許可するのはセカンダリネームサーバーのみだ。
In host1, edit /etc/namedb/db.example:
host1 の /etc/namedb/db.example を編集する。
zone "example.com" in {
type master;
file "db.example";
/* Only host2 and host3 can transfer this zone */
allow-transfer { 10.0.0.2; 10.0.0.3; };
};
In host1, edit /etc/namedb/db.10.0.0:
host1 の /etc/namedb/db.10.0.0 を編集する。
zone "0.0.10.IN-ADDR.ARPA" in {
type master;
file "db.example";
/* Only host2 and host3 can transfer this zone */
allow-transfer { 10.0.0.2; 10.0.0.3; };
};
Restrict zone transfer on any secondary too as attackers will try to zone transfer all authoritative dns servers.
攻撃者への対策としてゾーン転送をセカンダリに制限することにより、権威サーバーへゾーン転送を試みるようになる。
Restrict query: (問合せを制限する)
{ query はクエリ、検索、問合せなどと訳されるようだ。ここでは ipa に倣って「問合せ」にする。むしろ誤訳 満載のこんな怪しい文章よりも 4.2 サーバーサービスのセキュア化 - 4.2.2 BINDのインストールと設定 を読むこと }
Query is similar to mail open relay concept. Only trusted mail clients can relay mails through the mail server. With DNS, only trusted clients can query the server.
問合せは、電子メールのオープンリレーと同じ考えだ。信頼されたクライアントからの電子メールだけをメールサーバーへリレーする。DNS では、信頼されたクライアントからの問合せのみを扱うようにする。
/* Define my network */
acl "example.com-net" {
10.0.0.0/24;
};
In host1, edit /etc/namedb/db.example:
host1 の /etc/namedb/db.example を編集する。
zone "example.com" in {
type master;
file "db.example";
allow-transfer { 10.0.0.2; 10.0.0.3; };
allow-query { example.com-net; };
};
In host1, edit /etc/namedb/db.10.0.0:
host1 の /etc/namedb/db.10.0.0 を編集する。
zone "0.0.10.IN-ADDR.ARPA" in {
type master;
file "db.example";
allow-transfer { 10.0.0.2; 10.0.0.3; };
allow-query { example.com-net; };
};
Restrict recursive query: (再帰問合せを制限する)
Recursive query is a query send to the nameserver for the information which the local nameserver is not authoritative and must ask other nameservers for the answer. The answer is then feed back to the client and the nameserver will cache the information for future requests. Trusted DNS clients use this feature by listing nameservers in /etc/resolv.conf. Even if untrusted clients putting our nameservers in their /etc/resolv.conf and our nameservers to do the work for free, prevent this from happen with allow-recursion below.
再帰問合せは、ローカルネームサーバーから送信された問合せを、さらにネームサーバーへ送信する。権威サーバーではないが、あらゆるネームサーバーからの問い合わせに回答しなければならない{ 誤訳に注意 }。 回答はクライアントへ返され、ネームサーバーは次回の問合せのために情報をキャッシュする。信頼されたクライアントは /etc/resolv.conf に書かれたネームサーバーには使える。しかし、信頼されていないクライアントが /etc/resolv.conf に我々のネームサーバーを書き、ネームサーバーが問合せに無制限に回答させたいのであれば、以下のように書けばよい。{ なんかおかしいな }
Restrict recursive query to only trusted DNS clients:
信頼されたクライアントにのみ再帰問合せを制限する
/* Define my network */
acl "example.com-net" {
10.0.0.0/24;
};
options {
directory "/etc/namedb";
version "Expresso cup";
allow-recursion { "example.com-net"; };
};
Run BIND as non-root user inside chroot jail under NetBSD 1.5.1: ( NetBSD 1.5.1 で jail に chroot して 非 root ユーザーに BIND を実行させる)
Add named account to passwd using vipw:
vipw で named アカウントを追加する。
named:*:14:14::0:0:Named pseudo-user:/var/named:/sbin/nologin
Add named group to /etc/group:
/etc/group に named グループを追加する。
named:*:14:
Populate the chroot compartment:
たいていの chroot は以下のようになる。
# mkdir -p /var/chroot/named # cd /var/chroot/named # mkdir -p dev etc/namedb/cache usr/libexec var/run var/tmp # chmod 775 etc/namedb/cache # chown -R named:named etc/namedb/cache # chmod 775 var/run # chmod 01775 var/tmp # chgrp named var/run var/tmp # mknod dev/null c 2 2 # mknod dev/random c 46 0 # chmod 666 dev/null dev/random # chgrp named /etc/rndc.conf /etc/rndc.key # chmod 640 /etc/rndc.conf /etc/rndc.key # cp -p /etc/rndc.key /var/chroot/named/etc
Edit BIND startup configuration file so that it will run in chroot compartment with a non-priviledged user:
BIND のスタートアップ設定ファイルを編集し、chroot 環境で非特権ユーザーで走らせる。
Modify /etc/rc.conf.d/named9 and add -u named -t /var/chroot/named to named_flags:
/etc/rc.conf.d/named9 の named_flags に -u named -t /var/chroot/named を追加する。
named9=YES named_flags="-c /etc/namedb/named.conf -u named -t /var/chroot/named"
Edit BIND script to point from old location of pid-file to new one:
BIND スクリプトで新しい PID ファイルを参照するようにする。
# vi /etc/rc.d/named9
and change:
これを
pidfile="/var/run/${name}.pid"
to:
こうする
pidfile="/var/chroot/named/var/run/${name}.pid"
Copy BIND configuration files to chroot compartment and set proper permission:
BIND の設定ファイルをパーミッションを保持したまま chroot 環境へコピーする。
# cp -p /etc/namedb/* /var/chroot/named/etc/namedb
Restart BIND to pick up new changes:
BIND を再起動する。
# /etc/rc.d/named9 restart
Run BIND as non-root user inside chroot jail under NetBSD 1.5 current: ( NetBSD 1.5 current で jail に chroot して 非 root ユーザーに BIND を実行させる)
On 1.5X current, the chroot jail compartment is already populated and ready to use. All is needed is to copy the configuration files in /etc/namedb to /var/chroot/named/etc/namedb.
1.5X current では chroot jail 環境はすでに使えるようになっている。/etc/namedb にある設定ファイルを /var/chroot/named/etc/namedb へコピーすればよい。
# cp -p /etc/namedb/* /var/chroot/named/etc/namedb
Edit BIND startup config file so that it will run in chroot compartment with a non-priviledged user:
BIND のスタートアップ設定ファイルを編集し、chroot 環境で非特権ユーザーで走らせる。
Modify /etc/rc.conf.d/named9 and add -t /var/chroot/named and -u named to named_flags:
/etc/rc.conf.d/named9 の named_flags に -t /var/chroot/named と -u named を追加する。
named9=YES named_flags="-c /etc/namedb/named.conf -t /var/chroot/named -u named"
Starting with BIND 9.2.0, it requires /dev/random in chroot, so populate it:
BIND 9.2.0 で chroot するには /dev/random が必要なので以下のようにする。
# mknod /var/chroot/named/dev/random c 46 0
If the nameserver is a slave for any other domains, BIND needs to have write access to that directory. /var/chroot/named/etc/namedb/cache is where BIND will download other domain zones. Modify named.conf accordingly for the backup zones and make sure the file'' statement is referring to cache'' directory. e.g.:
ネームサーバーが他のドメインのスレーブになっている場合、BIND にはディレクトリへの書き込み権限が必要になる。BIND は /var/chroot/named/etc/namedb/cache に他ドメインのゾーンをダウンロードする。named.conf を編集し、ゾーンをバックアップするために file 文で cache ディレクトリを参照するようにする。
/* example.com zone name-to-address */
zone "example.com" in {
type slave;
file "cache/db.example";
masters { 10.0.0.1; };
allow-transfer { none; };
};
Running rndc to manage BIND in chroot environment requires proper permission.
chroot 環境で要求される権限で BIND を動作させるために rndc を走らせる。
Allow group BIND to use rndc in chroot:
chroot で BIND グループに rndc を許可する。
# chgrp named /etc/rndc.conf /etc/rndc.key
Only root and group BIND should know the secret key:
root と BIND グループにのみ秘密鍵を許可する。
# chmod 640 /etc/rndc.conf /etc/rndc.key
Finally, BIND needs to know the secret key when loading:
最後に、BIND が秘密鍵をロードできるようにする。
# cp -p /etc/rndc.key /var/chroot/named/etc
Start BIND in chroot:
chroot で BIND を起動する。
# /etc/rc.d/named9 start
Different DNS servers (他の DNS サーバー)
There are different type of DNS servers each serving a purpose. We have discussed and configured primary/master, secondary/slave. Others are cache only server, forwarding server and stealth server. Lets look at each one of them.
サービスの目的ごとに異なるタイプの DNS サーバーがある。プライマリ/マスターやセカンダリ/スレーブを設定できる。他のサーバーというのは、キャッシュサーバー、転送サーバ、ステルスサーバーだ。各々について見ていく。
Cache only name server: (キャッシュサーバー)
Cache only name server basically caches information that it receives and uses it until the data expires. A cache only server is not authoritative for any zone.
キャッシュサーバーは、基本的には受信した情報をキャッシュし、データの有効期間中は保持する。キャッシュサーバーはゾーンにたいして認証しない。
Here is an example configuration of a cache only server:
キャッシュサーバーの設定の例
/*
* file: /etc/namedb/named.conf
* purpose: cache only name server
*/
acl "example.com.internal" {
192.168.1.0/24;
};
options {
directory "/etc/namedb";
allow-query { "example.com.internal"; };
};
zone "0.0.127.IN-ADDR.ARPA" in {
type master;
file "db.127.0.0";
};
zone "." in {
type hint;
file "db.cache";
};
Stealth server: (ステルスサーバー)
From BIND9 ARM:
BIND9 の ARM { the Administrator's Reference Manual. 管理者向けリファレンスマニュアル } より
A stealth server is a server that answers authoritatively for a zone, but is not listed in that zone.s NS records. Stealth servers can be used as a way to centralize distribution of a zone, without having to edit the zone on a remote nameserver. Where the master file for a zone resides on a stealth server in this way, it is often referred to as a hidden primary'' configuration. Stealth servers can also be a way to keep a local copy of a zone for rapid access to the zone.s records, even if all official'' nameservers for the zone are inaccessible.
ステルスサーバーはゾーンの権威サーバーであるが、 NS レコードには書かない。ステルスサーバーはリモートのネームサーバーのゾーンファイルを編集しなくても、ゾーンの centralize distribution { ?????? } として利用できる。ここではステルスサーバーを「隠しプライマリ」として設定させるために、ステルスサーバーに master ファイルを設置する。正式なネームサーバーにアクセスできない場合は、ステルスサーバーはゾーンレコードに素早くアクセスするためにコピーを保持することも出来る。
Remote name daemon controller: rndc (リモートネームデーモン制御: rndc)
BIND comes with rndc and is a tool to manage a running BIND. To use rndc, an /etc/rndc.conf is required. rndc uses an authenticated link to communicate with the name server. This will reduce the chance of message spoofing the link.
BIND には制御ツール rndc が付属している。rndc を利用するためには /etc/rndc.conf が必要だ。rndc はネームサーバーと通信するために認証を使う。これによりメッセージなりすましをされる危険性を減らす。
Get rndc to work: (rndc を動作させる)
First, generate a shared secret key. The key will be used by rndc and named to authenticate each other.
最初に共有秘密鍵を作成する。rndc と named が認証のために使う。
# dnssec-keygen -a hmac-md5 -b 512 -n HOST int-example
will generate:
このようになる。
Kint-example.+157+23209.key Kint-example.+157+23209.private
the shared secret key is in either file.
共有秘密鍵は以下のようなファイルになる。
# cat Kint-example.+157+23209.key int-example. IN KEY 512 3 157 xCWxMply6q0NFFTIpL4Qf9qpFtg/DSADFSsdsdfgC9jq11QabdM+QHPaaOJG 9yzlnYp U0SWtSY10LXds6twdraoRsOA==
The last long string is the shared secret key, copy and and paste in the secret statement of /etc/rndc.conf. In /etc/rndc.conf, only options and key statements are required.
最後の長文は共有秘密鍵であり、/etc/rndc.conf の secret 文にコピーペーストする。/etc/rndc.conf には options 文と key 文のみが必要である。
/*
* /etc/rndc.conf for example.com
*/
// Key int-example.
key "int-example." {
algorithm "hmac-md5";
secret"vCWxMply6q0NFFTIpL4Qf9qpFtg/Du67g3IgC9jq11QabdM+QHPddOJG 9yzlnYpU
0SWtSY9LXds6twdraoRsOA==";
};
// Default server is localhost and key name is int-example.
options {
default-server localhost;
default-key "int-example.";
};
server localhost {
key "int-example."
};
In /etc/namedb/named.conf, declare the key and controls statement as below to enable the communicating channel.
/etc/namedb/named.conf では、通信チャネルを有効にするために key 文と controls 文を定義する。
// Use shared secret key for TSIG and rndc
key "int-example." {
algorithm hmac-md5;
secret"vCWxMply6q0NFFTIpL4Qf9qpFtg/Du67g3IgC9jq11QabdM+QHPddOJG 9yzlnYpU
0SWtSY9LXds6twdraoRsOA==";
};
// Allow rndc to connect to 127.0.0.1 on port 953
controls {
inet 127.0.0.1 allow { localhost; } keys { "int-example." ;};
};
To test rndc, try reload /etc/namedb/named.conf file with:
rndc をテストする。/etc/namedb/named.conf ファイルをリロードする。
# rndc reload rndc: reload command successful #
View /var/log/messages to see if BIND is reloaded successfully.
/var/log/messages を見ると BIND がリロードに成功したことが分かる。
To view statistics: (統計を眺める)
# rndc stats rndc: stats command successful #
A file /etc/namedb/named.stats is generated for viewing.
/etc/namedb/named.stats ファイルが生成されたことが確認できる。
TSIG: (TSIG)
TSIG stands for transaction signatures and is for server-to-server communication. Useful for dynamic update and zone transfer.
TSIG はサーバーとサーバー間通信におけるトランザクション署名である。動的アップデートとゾーン転送に利用する。
First create a shared secret key for use during zone transfer between master and slave:
最初にマスターとスレーブ間でゾーン転送するときの共有秘密鍵を作成する。
# dnssec-keygen -a hmac-md5 -b 512 -n HOST example-exslave.
Declare the key in /etc/namedb/named.conf:
/etc/namedb/named.conf で key を定義する。
// Use shared secret key for TSIG and rndc
key "muine-secondary." {
algorithm hmac-md5;
secret"4BQV4cc6JbE5wlMlVr/+HdO2G7qzBZOSxsrpyR5QjSMXqPm37ZIHZc8x LcsIG6XE
MLnzGK+H3NC7I4Xeoc70Jw==";
};
For the the zone you want to permit slave to transfer add:
スレーブに転送を許可するならば transfer にスレーブを追加する。
// All zone transfers to those signed with the example-other key
allow-transfer { key example-other. ;};
At this point, if the local name server receives a message signed with this key, it can verify the signature. If the signature succeeds, the response is signed by the same key.
ここで、ローカルのネームサーバーがこの鍵で署名されたメッセージを受信すると、署名を検査する。署名が正しければ、応答は同じ鍵で署名される。
When using shared secret, /etc/namedb/named.conf should not set to world-readable. Transfering key from one server to another using ssh is better than telnet. TSIG requires that the clocks be no more than 5 minutes apart between master-slave because it will timestamp TSIG record to prevent replay attacks. Make sure your clock is synchronize properly.
共有鍵を使う場合、/etc/namedb/named.conf は誰でも読めるようにしないほうがよい。サーバーから別のサーバー鍵を転送する場合は telnet するよりも ssh するほうがよい。TSIG は、マスターとスレーブの間の時差が 5 分未満であることを要求する。TSIG は、リプレイアタックを防ぐためにタイムスタンプを記録するのである。クロックは同期させておこう。
Tell local name server to sign all requests with key if it's the one who initiates the transaction.
ローカルネームサーバーがトランザクションを開始するときに全てのリクエストに鍵で署名する。
// Sign all requests with key example-other when communicating with 10.10.0.0
server 10.10.0.0 {
keys { example-other. ;};
};
Run DNS for your own domain (独自ドメインで DNS を走らせる)
If you're one of those people with a static IP address and a registered domain name, you might want to consider running your own DNS instead of relying on somebody else.
あなたが固定 IP アドレスを持っていて、ドメイン名をレジストラに登録しているならば、自分で DNS を運用してみるとよい。
First, update example.com DNS information at the domain registry where it was registered so that your new DNS will become the authoritative nameserver. Second, arrange with a friend to act as secondary DNS. Alternatively, use free 3rd party like Secondary.com or The Public DNS Service. Read DJB's Third-party DNS service page for some caveats.
最初に、自分の DNS で権威サーバーを持つために、レジストラに登録してある example.com の DNS 情報を更新する。次に、友人にセカンダリ DNS を依頼する。または Secondary.com のようにフリーのサードパーティを使うか、The Public DNS Service を使う。DJB のサードパーティ DNS サービスについての注意ページ { Costs and benefits of third-party DNS service }を読んでおくこと。
The idea is to ask the domain registry to ``delegate'' example.com domain requests to your own DNS server and find a backup for the domain just in case your DNS is unreachable.
これは、example.com ドメインの問合せをレジストラから自分の DNS に委譲し、自分の DNS が不達になったときのためにバックアップさせる、ということをやっている。
Here are what the domain registry required to update their DNS for proper delegation. Note that the information below are ficticious:
レジストラから委譲してもらうために DNS 情報を更新してもらう。たとえばこう。
domain to delegate: example.com
primary dns server for example.com: ns.example.com
ns.example.com IP address: 10.0.0.1
secondary dns server for example.com: ns.other.com
ns.other.com IP address: 172.16.0.1
Here is how it is going to look like in the parent/name registry DNS zone: (親ネームサーバーから DNS ゾーンを委譲してもらうとこうなる)
; ; Delegate example.com to ns.example.com DNS ; Name CLASS TTL TYPE RR Data example.com 86400 IN NS ns.example.com 86400 IN NS ns.other.com ns.example.com 86400 IN A 10.0.0.1 ns.other.com 86400 IN A 10.0.0.2
The last 2 lines are called glue records. Glue record is an A record where the name appears on the right hand side of an NS record.
最後の 2 行はグルーレコードと呼ばれる。グルーレコードは、NS レコードの右側と同じ値を A レコードに記述する。
Setup example.com zone to answer requests from the internet: (example.com ゾーンをインターネットからの問合せに回答するようにする)
/* Global options */
options {
directory "/etc/namedb";
auth-nxdomain no;
recursion no;
};
/* Control logging behaviour */
logging {
category lame-servers { null; };
};
/* example.com zone name-to-address */
zone "example.com" in {
type master;
file "db.example";
allow-transfer { 172.16.0.1; };
};
/* example.com zone address-to-name */
zone "0.0.10.IN-ADDR.ARPA" in {
type master;
file "db.10.0.0";
allow-transfer { 172.16.0.1; };
};
/* loopback zone address-to-name */
zone "0.0.127.IN-ADDR.ARPA" in {
type master;
file "db.127.0.0";
};
/* root hint zone */
zone "." in {
type hint;
file "db.cache";
};
/* example.com zone name-to-address */
;
; Default Time To Live for records with undefined TTLs
;
$TTL 86400
@ IN SOA ns.example.com. hostmaster.example.com. (
2001092401 ; serial
43200 ; refresh after 12 hours
3600 ; retry after 1 hour
1209600 ; expire after 2 weeks
86400 ; minimum negative cache TTL of 1 day
)
;
; Nameservers
;
IN NS ns.example.com.
IN NS ns.other.com.
;
; Mail servers
;
example.com. IN MX 0 ns.example.com.
IN MX 10 ns.other.com.
;
; example.com
;
IN A 10.0.0.1
;
; ns.example.com
;
ns IN A 10.0.0.1
;
; Aliases:
; www.example.com
; ftp.example.com
;
www IN CNAME ns.example.com.
ftp IN CNAME ns.example.com.
/* example.com zone address-to-name */
;
; Default Time To Live for the zone
;
$TTL 86400
@ IN SOA ns.example.com. hostmaster.example.com. (
2001092401 ; serial
43200 ; refresh after 12 hours
3600 ; retry after 1 hour
1209600 ; expire after 2 weeks
86400 ; minimum negative cache TTL of 1 day
)
;
; Nameservers
;
IN NS ns.example.com.
IN NS ns.other.com.
;
; Reverse mapping for ns
;
1 IN PTR ns.example.com.
And the usual loopback zone address-to-name...
あとループバックゾーンの逆引きを追加したり
And the usual root hint zone...
ルートヒントゾーンを追加したり
Setup other.com zone to backup for example.com: (example.com のバックアップとして other.com を設定する)
other.com will be able to transfer db.example and db.10.0.0 from example.com primary dns server. For other.com db.other and db.172.16.0 should have similar entries as example.com's db.example and db.10.0.0 zone files.
other.com は example.com のプライマリ DNS サーバーから db.example と db.10.0.0 を転送してもらう。other.com の db.other と db.172.16.0 は example.com の db.example と db.10.0.0 ゾーンファイルと同じようにする。
/* Global options */
options {
directory "/etc/namedb";
auth-nxdomain no;
recursion no;
};
/* Control logging behaviour */
logging {
category lame-servers { null; };
};
/* example.com zone name-to-address */
zone "example.com" in {
type slave;
file "db.example";
masters { 10.0.0.1; };
allow-transfer { none; };
};
/* example.com zone address-to-name */
zone "0.0.10.IN-ADDR.ARPA" in {
type master;
file "db.10.0.0";
masters { 10.0.0.1; };
allow-transfer { none; };
};
/* other.com zone address-to-name */
zone "0.16.172.IN-ADDR.ARPA" in {
type master;
file "db.172.16.0";
allow-transfer { none; };
};
/* loopback zone address-to-name */
zone "0.0.127.IN-ADDR.ARPA" in {
type master;
file "db.127.0.0";
};
/* root hint zone */
zone "." in {
type hint;
file "db.cache";
};
Familiarize with DNS tools (NS ツールに慣れる)
DNS debugging tools (DNS デバッグツール): host,dig,nslookup,dnswalk,doc
To find out mail exchange for example.com:
example.com の mail exchange を探す
# host -t mx example.com
To find out name server for example.com:
example.com のネームサーバーを探す
# host -t ns example.com
To manually transfer zone example.com:
example.com へ手動でゾーン転送する
# dig @ns.example.com AXFR example.com
Use dnswalk to test example.com:
dnswalk で example.com のテスト
# dnswalk -d example.com.
Use doc to verify that example.com is configured and functioning correctly:
example.com の設定と機能を検証するために doc を使う。
# doc example.com
doc will produce log.example.com. file with all the information needed to verify the correctness of example.com
doc は example.com の検証結果を log.example.com ファイルに保存する。
To find out the authors of BIND:
BIND の著者を探す。
% dig @ns.example.com authors.bind chaos txt
Load balance (round robin): (ロードバランス (ラウンドロビン))
BIND supports load balancing between 2 or more IP addresses. Ping postoffice will
BIND は 2 つ以上の IP アドレスのロードバランスに対応している。postoffice に ping してみる。
; Name TTL CLASS TYPE RR Data
postoffice 300 IN A 10.0.0.2
300 IN A 10.0.0.3
$ ping postoffice PING postoffice.example.com (10.0.0.2): 56 data bytes ... 1 packets transmitted, 1 packets received, 0.0% packet loss $ ping postoffice PING postoffice.example.com (10.0.0.3): 56 data bytes ... 1 packets transmitted, 1 packets received, 0.0% packet loss
The order will be: 10.0.0.2,10.0.0.3 and 10.0.0.3,10.0.0.2 and back to 10.0.0.2,10.0.0.3 and so on.
10.0.0.2、10.0.0.3 という順番が 10.0.0.3、10.0.0.2 になり、10.0.0.2、10.0.0.3 に戻っている。
Reference (参考)
BIND home: http://www.isc.org/products/BIND/
DNS rfc: http://www.example.com/rfc/rfc1035.txt/
DNS and BIND bible: http://www.ora.com/catalog/dns4/
comp.protocols.tcp-ip.domains Frequently Asked Questions http://www.intac.com/~cdp/cptd-faq/
Name Server Operations Guide for BIND http://www.irbs.com/bog-4.9.5/
Read BIND Administrator Reference Manual: http://www.nominum.com/resources/documentation/Bv9ARM.pdf
Mr. DNS questions archive: http://www.acmebw.com/askmrdns/ http://www.menandmice.com/9000/9300_DNS_Corner.html
DNS Resources Directory: http://www.dns.net/dnsrd/
DNS implementation by qmail author: http://cr.yp.to/djbdns.html
Operational guidelines for Root Name Servers. http://www.muine.org/rfc2870.txt
Common DNS Operational and Configuration Errors http://www.muine.org/rfc/rfc1912.txt
Selection and Operation of Secondary DNS Servers http://www.muine.org/rfc/rfc2182.txt
Tools for DNS debugging http://www.muine.org/rfc/rfc1713.txt ftp://ftp.uu.net/.vol/1/ip/dns/
Securing an internet name server http://www.nsiregistry.com/dns/securing_an_internet_name_server.pdf
Running BIND9 in a chroot cage using NetBSD's new startup system http://www.daemonnews.org/200110/named-chroot.html
last update: July 27, 2003
2011-02-25 :-(
_ [jail][chroot][NetBSD][翻訳]Securing Systems with chroot - O'Reilly Media
chroot でのセキュアシステム
by Emmanuel Dreyfus
01/30/2003
Buffer Overflows (バッファーオーバーフロー)
One popular technique crackers use to compromise machines is exploiting buffer overflows. Buffer overflows are programming bugs which often plague software written with the C language, which makes such mistakes easy to make. Here is an example:
クラッカーたちがマシンを破るときに常用するのがバッファーオーバーフローを利用したものだ。バッファーオーバーフローは C で書かれたソフトウェアにときどき潜むバグで、簡単にミスる。たとえばこう。
int getfilename(void)
{
/*
* dos filenames are 8 chars + one dot + 3 chars + trailing nul char
* => total 13 chars
*/
char tmp[13];
(void)scanf("%s", tmp);
/* more code, more bugs... */
return 0;
}
So what happens? The programmer has expected the user to supply a DOS filename, which should fit in a 13 character buffer. Unfortunately, he has failed to validate user input. If the user types a filename which is 25 bytes long, scanf() will copy all the 25 bytes in the buffer, which is only 13 bytes long. The extraneous data will overwrite memory locations near the buffer.
これで何が起きるのか? プログラマは、ユーザーが DOS ファイル名( 13 文字だ )を与えることを期待している。しかしユーザーの入力を検証しようとすると失敗する。ユーザーが 25 バイト以上のファイル名を入力すると、scanf() は 13 バイトぶんしかないバッファーに 25 バイト全てをコピーしようとする。そしてバッファーの近くにあるメモリを上書きするのである。
Local variables such as the buffer used in this example are allocated on a memory area called the stack. The processor maintains the stack, using a register known as the stack pointer to keep track of the memory location of the top of the stack. The stack pointer moves with every function call, and some or all of the following data is pushed on the stack: the current contents of the CPU's registers, the arguments to the function, and a placeholder for the function's return value. Additionally, a placeholder for local variables is created.
この例のバッファーのように、ローカル変数にたいしてメモリを確保したものは、スタックと呼ばれる。プロセッサがスタックを管理しており、確保したメモリのスタックポインタを保持するためにレジスタが使われる。スタックポインタはあらゆる関数呼び出しで移動され、CPU レジスタの現在値、関数の引数、関数の戻り値の placeholder のうちいくつか、あるいは全てのデータがスタックに乗せられる。さらに、ローカル変数の placeholder が作成される。
On a function return, the stack pointer moves down, and the CPU registers are restored from the values stored on stack. Thus the calling function gets its context restored and is not disturbed by the actions of the called function did.
関数が戻るとスタックポインタは下り、CPU レジスタはスタック上に置かれた値を復帰させる。このように、関数呼び出しはコンテキストを復帰させ、関数呼び出しによる影響を受けないようになっている。
What is overwritten when our buffer overflows? First, other local variables, the return value of the function, the function's arguments...then, the saved CPU registers, including the address to which the CPU should return when it completes the called function. A buffer overflow corrupts this value, and the function will return somewhere else in memory. The odds are against finding valid code there. The program will terminate on an illegal instruction, an address error, or perhaps a segmentation fault.
バッファーオーバーフローで上書きされると何が起きるのか? 最初に、関数の戻り値や関数の引数のローカル変数があるとする。そして、関数呼び出しが完了したときに CPU が戻るアドレスも CPU レジスタに格納される。バッファーオーバーフローはこの値を破壊し、関数をメモリ内のどこか別のところに返す。そしてどこかのコードに辿りつく。プログラムは不正な命令により終了し、アドレスエラーやセグメンテーションフォルトを発生させる。
Exploiting Buffer Overflows (バッファーオーバーフロー攻撃)
If the user happens to be a clever cracker, he could enter data which is valid machine code, overwriting the return address with the address of his code. We end up with the situation where the user has successfully tricked our program into executing his code.
ユーザーが賢いクラッカーならば、彼のコードに帰るアドレスで上書きするために、マシンコードとして有効なデータを仕込む。プログラムにこれを仕込まれ、彼のコードが実行されたら、我々はお手上げである。
This is a real problem if the program is running under a privileged user ID, such as the system superuser (root). An attacker could execute his code with the privileges of a superuser. The next step for our cracker is to include an exec() system call and execute a command such as /bin/sh with superuser privileges to gain full control of the machine.
プログラムがシステムのスーパーユーザー ( root )などの特権ユーザーで実行されているとしよう。攻撃者は特権を持つスーパーユーザーとして彼のコードを実行できるのである。次にクラッカーは exec() システムコールを仕込み、/bin/sh のようなでコマンドを特権スーパーユーザーで実行し、マシンの全制御を得るのである。
There are various places in the system where such a situation can arise: setuid binaries (su, passwd, pppd), privileged programs which parse user files (sendmail, cron), and network daemons which answer user requests (sshd, named, ntpd, and so on). Problems in network daemons are critical since they mean that a remote user can compromise the system over the Internet.
これはシステム内の様々な箇所で発生しうる状況である。setuid バイナリ (su, passwd, pppd)、ユーザーファイルを解析する特権プログラム(sendmail, cron)、そしてユーザーリクエストに回答するネットワークデーモン(sshd, named, ntpd など)。ネットワークデーモンでの問題は、リモートユーザーがインターネットを超えてシステムをどうにでも出来るという致命的な問題である。
Enhancing security by using chroot jails (chroot jails によるセキュリティ強化)
Securing programs which take some user input is not easy. The errors are not always as obvious as a buffer overflow. Additionally, since the complexity of network services is always increasing, many programs use third party libraries which provide services such as compression or cryptography. Security problems in those libraries can compromise the security of any program that uses them, something that developers cannot necessarily anticipate.
ユーザー入力についてセキュアにプログラミングすることは容易ではない。エラーは、バッファーオーバーフローのようにいつも明確なわけではない。加えて、ネットワークサービスの複雑さはつねに増大しているし、多くのプログラムが圧縮や暗号化などのサードパーティ製ライブラリを使用している。これらのライブラリにあるセキュリティ問題は、そのライブラリを使うプログラムにも影響するし、開発者はそれらの問題を予見することは出来ない。
One solution is to admit that network daemons are inherently insecure. Therefore, the best option is to reduce the consequences of a security exploitation.
1 つの解決策は、ネットワークデーモンは本質的にセキュアではないと認めることだ。ゆえに、最良の選択肢はセキュリティ攻撃を減らすことだ。
The first measure is to run the service as a non-privileged user. That way, an intruder who breaks into the machine will not have full control. Daemons such as innd (Internet Network News Daemon) and ircd (Internet Relay Chat Daemon) use this behavior by default.
最初にやることは、非特権ユーザーでサービスを走らせることだ。こうすることで、侵入者がマシンを破ったとしても全制御されることはない。innd (Internet Network News Daemon) と ircd (Internet Relay Chat Daemon) は既定でこの動作をする。
This is a good first measure to tighten system security, but it is not perfect. Once the intruder has a shell access with the privileges of the compromised daemon, even though it is unprivileged, he can still affect the compromised daemon and look for local security flaws, such as might exist in other setuid binaries.
システムのセキュリティを強固にするにはよいのだが、完璧ではない。非特権であっても{ it はどれを指している???? } 侵害されたデーモンの特権でシェルを使えるようになった場合、侵害されたデーモンに影響を及ぼし、setuid されたバイナリといったローカルセキュリティの穴を探すことを許してしまう。
An additional measure is to chroot the daemon. Chrooting is a verb named after the chroot(2) system call, which is used to change the root of the filesystem as seen by the calling process.
ほかに、デーモンを chroot する方法がある。Chrooting とは、chroot(2) システムコールを呼んだあとの状態のことである。プロセス呼び出しのときのファイルシステムの root を変更するときに使う。
When a process requests to chroot to a given directory, any future system calls issued by the process will see that directory as the filesystem root. It becomes impossible to access files and binaries outside the tree rooted on the new root directory. This environment is known as a chroot jail.
与えられたディレクトリに chroot する要求がプロセスからあると、今後のあらゆるシステムコールはそのディレクトリをファイルシステムの root とみなして動作するようになる。これで新しい root ディレクトリの外のディレクトリツリーのファイルやバイナリにアクセスすることが出来なくなる。この環境は chroot jail として知られている。
It is possible to experiment with chrooting easily. Just create a tree with a few binaries, including root's shell as listed in /etc/passwd:
簡単な chroot を試すことが出来る。/etc/passwd に書いてある root 用シェルを含めていくつかのバイナリのためにディレクトリを作るだけだ。
/tmp/bin/sh /tmp/bin/ls
If these binaries are dynamically linked on your system (this is the case on most Linux distributions), make sure you include the dynamic linker and the required libraries (typically /lib/ld.so.1 and /lib/libc.so.1).
あんたのシステムでこれらのバイナリが動的リンクされている( Linux ディストリビューションンではよくあること )ならば、動的リンカと、必要なライブラリ ( /lib/ld.so.1 や /lib/libc.so.1 など )も含めること。
You can then try the chroot(1) command, which just performs the chroot(2) system call and runs a shell. Only root can use this command:
そうしたら chroot(1) コマンドを実行する。これはたんに chroot(2) を実行し、シェルを走らせるだけだ。root でやること。
# ls / bin etc dev home sbin tmp usr var # chroot /tmp # ls / bin # ls /bin sh ls
Once you are in the chrooted shell, you only have access to the chrooted area. There is no way to escape it; you are in the jail. Other processes still see the normal filesystem root as the root of the filesystem.
chroot なシェルに入ったら、もはや chroot された領域にしかアクセスできない。jail に入ったら脱出する手段は無い。他のプロセスでは、ファイルシステムの root が普通のファイルシステムの root に見えるだろう。
However, there are some ways of getting out of a chroot jail if the process is still running with superuser privileges. It is possible to do a mount(2) system call in order to remount the real root filesystem and then to chroot in it. It would also be possible to create a /dev/kmem device using the mknod(2) system call, and then modify the filesystem root in kernel memory. If the chrooted process runs with superuser privileges, there are many ways of breaking out of the chroot jail. This is why, when chrooting a process, the user ID should always be changed to a non-privileged user.
しかし、プロセスがスーパーユーザー特権を持っていると、chroot から脱出できてしまう。mount(2) システムコールによって実際のファイルシステムの root をマウントし、そちらに chroot できてしまう。mknod(2) システムコールで /dev/kmem を作成し、ファイルシステムの root をカーネルメモリーに確保することでも可能である。プロセスがスーパーユーザー特権で動作していると、いくつもの方法で chroot jail を脱出できるのである。ということで、chroot させるプロセスは必ず非特権ユーザーのユーザー ID に変更すること。
The only way left for an unprivileged process to get out of a chroot jail would be to exploit a kernel security hole. If there is some buffer overflow on a system call argument, it could be possible to execute some code with kernel privileges and to set a new filesystem root for the process. Great care is taken when validating system call arguments, so this should not happen. This kind of security hole has been encountered in the past, but there has been much less problem with system call argument validation than with buffer overflows in network daemons and setuid binaries. For an example of a real system call buffer overflow, take a look at this sobering paper.
非特権プロセスが chroot jail を脱出する方法はただひとつ。カーネルのセキュリティホールを突くしかない。システムコールの引数でバッファーオーバーフローを起こせば、何らかのコードをカーネル特権で実行できるようになり、プロセスに新しいファイルシステム root を設定するのである。システムコールの引数を評価するように注意すればよい。そうすれば発生しない。この種のセキュリティホールは日常的によくあるのだが、ネットワークデーモンや、setuid されたバイナリはシステムコールの引数を評価することにより問題を最小限にしている。ここでは実際のシステムコールのバッファーオーバーフローの例をお見せした。
Summary (まとめ)
We have seen one common security flaw and have learned how it may be exploited. We have also discussed one approach to minimizing this damage. chroot is not perfect, but, with care, it can lead to more secure systems. Next time we will demonstrate how to run a daemon (ntpd) chrooted on NetBSD.
どこにでもあるような 1 つのセキュリティ欠陥と、それがどう悪用されるのかを見てきた。そのダメージを最小限にする方法についても議論した。chroot は完璧ではないが、システムをさらにセキュアにするためには使える。次回は、NetBSD の chroot でデーモン (ntpd) を走らせてみよう。 { その次回の記事が無いよ!!! }
Editor's Note: an earlier version of this article had reversed the arguments to scanf(). This has been corrected.
著者注: この文書の初期では scanf() の引数が逆だった。いまは正しい。
Emmanuel Dreyfus is a system and network administrator in Paris, France, and is currently a developer for NetBSD.
2011-02-26 :-)
_ マミさん
肉体が破壊されていてもソウルジェムが破壊されてなければ唐突に戦線復帰することもあるんじゃなかろうかと思ったが、まあなさそうだ。全部喰われてそうだし
