If you can't understand it choose other language...
[English] [Russian] [French] [Czech] [日本語] [翻訳して貴方の使ってる言語のページを追加しましょう]

初心者のためのRSBAC

はじめに

コンピュータを要塞化する作業を始める前に、一体何が必要な事なのかを考えておきましょう。 どんなセキュリティシステムでも生活に様々な制限をかけますし、 多大なセキュリティシステムは多大な制限を課します。 チェックと認証の追加はkernelの生産性を低下させますし、 安全なファイル削除のような仕組みはファイルシステムの速度低下をもたらします。

「スーパーユーザ」という存在を忘れましょう、これは最も深刻なセキュリティの問題の一つです。 そして「システム管理者」と「セキュリティオフィサー」を別々のアカウントにしましょう。 それぞれのアカウントは互いに影響を与えるようなことはできませんし、 システム権限において競合します。 引き続きシステム管理者は、システムの運用・設定・ユーザの追加と削除・ ユーザによるシステムリソースの使用制限などの作業が可能です。 セキュリティオフィサーは、(システム管理者をも含めた)全てのユーザーに対して (システムも含めた)あらゆるデータへのアクセスへの制限をします。 例えば、システム管理者はユーザの追加・削除が可能ですが、 セキュリティオフィサーから許されない限り /etc/passwd や /etc/shadow のようなファイルを手動で編集することはできません。

注意！！次の変更は慎重に行ってください。 システムの「全て」に対してアクセスを拒否されるかもしれず、 この際 single user モードさえも役に立ちません (カーネルに対して何のパラメータを与えることも出来ません）。 助かる唯一の方法は標準のLinuxカーネルで起動することです。

さぁ、今までに挙げた問題を恐れていませんか、ならば早速はじめましょう！ でなければ、古くさいUNIXのセキュリティシステムにしがみ付いてください...

カーネルの作成

必要なもの

  1. 主要ソースコード - rsbac-version.tar.gz か rsbac-version.tar.bz2
  2. 管理ツール - rsbac-admin-version.tar.gz
  3. カーネルパッチ

最新バージョンのRSBACをダウンロードしましょう(http://www.rsbac.org/)。 ２つのファイルが必要です： rsbac-current-version.tar.gz と rsbac-admin-current-versions.tar.gz になります。 最初のファイル( rsbac-current-version.tar.gz )はカーネルパッチとRSBACのメインソースコードが含まれており、 ２つ目のファイル( rsbac-admin-current-versions.tar.gz )には管理ユーティリティが含まれています。

新しいユーザとして secoff を UID 400 で追加することが必要です。 最初の起動時にこのユーザーは自動的にセキュリティオフィサーとなります。

カーネルソースを /usr/src/linux に展開し、 rsbac-current-version.tar.gz も同じディレクトリに展開してカーネルに対して RSBAC カーネルパッチを適用します： (patch -p1; patch-kernel-version というように行います)

利用するカーネルのバージョンに必要なカーネルパッチについては /http://www.rsbac.org/ のパッチディレクトリで見つかります。 バージョン1.0.9aとそれ以前ではパッチは主要ソースコードの中にあります。

そして make menuconfig を行うと新たなメニュー項目 "Rule Set Based Access Control (RSBAC)" が現れます。RSBACの世界へようこそ！

標準カーネルを変更してRSBACメニュー項目へ行きます。 以下に挙げる項目にチェックを入れてください。

RSBAC proc support
/proc のサブディレクトリに rsbac-info ファイルが見えるようになります。 これは管理ユーティリティが正常に動作するために必要です。 RSBACの設定完了後、この項目を削除してしまうことが可能になり、 その場合、侵入者はRSBACの存在を知ることが出来なくなるでしょう。
RSBAC maintenance kernel
２つのカーネルを作成します。 このうち１つはこの項目が有効になっているもの(これをメンテナンスカーネルと呼びましょう) ともう１つはこの項目が無効となっているもの(メインカーネル)です。 メンテナンスカーネルによって 通常のRSBACシステムのコントロールが出来なくなってしまった際に レスキューカーネルとして使用することができます。
support secure_delete
本当の意味でのセキュアな削除ではなく、単に0で埋めるだけです。 この項目を有効にした場合、ファイルシステムのパフォーマンスは低下します。

RSBACはモジュラー型の構造になっており、 それぞれ独自の方式でアクセスをチェックするいくつかの認証モジュールを含んでいます。 最終的な決定は全てのモジュールを通過してから行われます。 全てのモジュールによって利用されることになるAUTHモジュール以外の全てのモジュールは、全く独立した動作をします。 ここでは4つのRSBACモジュールのみを見ることにしましょう。 以下の通りです：

AUTH
汎用的なプロセスのトラッキング。プログラムは許可が無い限りUIDを他のものに変更することは出来ません。
RC(Role Compatibility)
大変強力な役割型アクセスモデル(Role Base model access) 。 有用かつ興味深いものです。 RCを使うことによってセキュリティ問題の大部分を解決することが出来ます。
MAC(Mandatory Access Control 強制的アクセスコントロール)
Bell-La Padulaモデルとしてよく知られている強制的アクセスモデルをベースとしたもの。 セキュリティ理論としてはとても有用、実際の運用は非常に難しい。
ACL(Access Control Lists)
システム内で個々のユーザのアクセス権限を定義できます。

上記のモジュールを有効にして、その他を無効にするべきです。 当然のことですが、選択した項目では "NAME-OF-MODULE protection for AUTH module" を有効にするだけで、 "NAME-OF-MODULE protection by role" を有効にしてはいけません。

これらの設定を完了後、カーネルを make しましょう：メインカーネルと メンテナンスカーネルです。 最初にメインカーネルを make して /boot にコピーし、"RSBAC maintenance kernel" 項目を有効にして再度 カーネル を make します。

さて、ここで管理用ユーティリティの作成が必要です。 適当なディレクトリで rsbac-admin-*-*.tar.gz を展開しましょう。 次にユーティリティを make して install します。 多分 Makefile 中の KERNELDIR パラメータ を変更する必要があると思います。

ユーティリティをインストールした際に、/rsbac ディレクトリ が作成されます。 これは後にアクセスデータベースとして利用されます。 何か試した後でシステムにアクセスできなくなった際は、 useraciを除いたこのディレクトリのファイル全てを削除可能です(これは通常のカーネルで行う必要があります)。 マウントしたパーティション全てで /rsbacディレクトリ 以下を削除する必要があります。

バージョン1.0.9bでの重要な変更：管理ツールのインストールは/rsbacを作らなくなりました。 その代わり、カーネル 部分では rsbac/useraci (実際のファイルではなく、単にデフォルトの設定)が存在しない場合、 それを作成します。 そのため、useraci を削除する必要があります。 そうしない場合、おそらくユーザーには設定されていない権限が与えられるでしょう。 これがカーネルがuseraciを自動的に作成した主な理由でした。

さて、カーネルとユーティリティができたとします。続けましょう。 最初の起動後いくつかのサービスが動作せず、皆あなたを呪い、rootだけがシステムにloginできます。 慌てないで、全く問題ありません。プログラムの権限を制限したので、動かなくなったのです。 権限を調整すればシステムはまた動き出します。 まず、システムにセキュリティオフィサーとしてloginする必要があります。 まず、新しいカーネルにパラメータとして rsbc_auth_enable_login を渡してシステムを再起動します (これは初回にのみ付け加える必要があります)。 次に、メンテナンスカーネルで再起動し、rootとしてloginして次のようなコマンドを入力します：

attr_set_fd FILE auth_may_setuid /bin/login

この後、システムを起動して、セキュリティオフィサーとしてloginし、 セキュリティモデル理論を読むために本棚へ行きましょう。

AUTH モジュール

このモジュールはプロセスのUID変更をコントロールします。 それぞれのファイルに以下のパラメータがあります：

auth_may_setuid
プロセスは通常のカーネルと同様に動作します。 そのため、UIDを如何なる制限もなく変更する事が可能です。 /bin/login にはこの権限が必要です。
auth_capabilities
プロセスがどのUIDに変更できるかのリスト。 例えば、リストに23,25,45とある場合、そのプロセスはUIDを23,25,45に変更可能で、 66には変更できません。

練習問題： さて、これで最初の起動時に見たサービスのエラーを修正できます。 まず、システムのログを見て(secoffは単なるユーザなので、 この作業にはroot権限が必要です)、エラーメッセージを探します。 下に挙げるようなエラーを見付けられたらこの問題を修正できますが、そうでなければ後で行いましょう。

Feb 25 12:58:13 stas kernel: rsbac_adf_request(): request CHANGE_OWNER, caller_pid 77, caller_prog_name portmap, caller_uid 0, target-type PROCESS, tid 77, attr owner, value 1, result NOT_GRANTED by AUTH

このメッセージが示しているのは、現在 UID 0 の portmap プロセスが UID 1(value 1) に変更しようとして( CHANGE_OWNER )、 AUTH moduleがこのリクエストを拒否したということです。 さぁ、RSBAC に対して portmap がこの動作を行っても良い事を教えてやりましょう。 e.g. auth_capabilities リストに UID 1 を加えます。 



付記：(RSBACがどの様にしてlogメッセージを表示しているか)
通常、RSBACは以下のような仕組みのカーネルメッセージを利用している。

---------------------------------------------
Kernel
----------    ----------------
|        |    |              |
| printk |    | rsbac_printk |
| kernel |    | kernel       |
| buffer |    | buffer       |
|        |    |              |
----------    ----------------
----|-----------------|----------------------
  /proc/kmsg         /proc/rsbac-info/rmsg
    |                 |
    |                 |
  klogd              rklogd (or other program)
    |                 |
    |                 |
    |                /home/secoff/rsbac-messages
  syslogd
    |
    |
  /var/log/messages


RSBACは通常のsyslog機能か proc/rsbac-info/rmsgファイル(または rsbac_syslog() システムコール)
を利用した独自のログ機能を利用可能です。
この場合、セキュリティオフィサーだけがRSBACメッセージを読む事ができます。
もし、/var/logをRSBACのメッセージで埋め尽くしたくない、
またはセキュリティ関連のメッセージを保護したい場合は、
カーネルコンフィギュレーションで特定の項目("don't log to syslog")を有効にする必要があります。

セキュリティオフィサーとしてloginしてメイン管理プログラム rsbac_menu を起動します。 "File/Dir Attributes"メニューに移動し…この大量の選択可能な権限リストを見る準備はできていますか？ これがRSBACが持つモジュラー構造の結果なのです。 それぞれのモジュール(とセキュリティモデル)は個々に権限のマッピングを持っています。

さぁ、設定をしましょう。 "File/Dir List:Choose from listing of last dir"メニューから portmap ファイルを選んでください。 そして auth_capabilitiesメニューへ移動し、新しくUID 1を追加します。 これでportmapプログラムが設定されて次回起動時にエラーを吐かなくなります。

他のエラーメッセージの対処も同様の方法で行います。 私の経験上からいうと、このような作業を少々行った後、システムは以前同様に動くようになります。

MAC モジュール

AUTHモデルはとてもパワフルですが、とてもシンプルです。 他のモジュールの場合はそんなに簡単ではありません。 MACモジュールは Multics OS 用の Bell and La Padulaモデルによってもたらされる セキュリティモデルを実現します。 まず、この理論を理解するところから始めましょう。

ここに２つのセットがあります： オブジェクト"O"のセットとサブジェクト"S"のセットです。 オブジェクトはファイル、ディレクトリ、共有メモリ、パイプ、メッセージキュー、その他システムリソースです。 サブジェクトはユーザとユーザが起動したプロセスです。

サブジェクトはオブジェクトへのアクセス権限を得ようとします。 セキュリティシステムはサブジェクトの権限をチェックし、その行動を許可／拒否を行います。 この決定を行うのに明確なクライテリアが必要なのは明白です。 強制的アクセスモデルではクライテリアは強制レベルです。 強制レベルはセキュリティレベル"L"(マイナスではない)とカテゴリー"M"(64bitのベクタ)セットから構成されています。

２番目のベクタの１と最初のベクタの１が一致した場合、カテゴリM1は(定義により)カテゴリM2を上書きします

例(3bitベクタの場合)

M1 {1,0,1} は M1 {1,0,0} を上書きする。 M3 {0,0,1} は M4 {0,0,0} を上書きする。

Li>Lj に加え Mi が Mj を上書きする場合、ラベル {Li,Mi} は(定義により)ラベル{Lj,Mj} を上書きする。

この定義にはいくつか特別な定義が必要になります。

まず、サブジェクトSiのオブジェクトOjに対する権限(読み取り、書き込み、実行、そしてその他...) を含むDijが存在するアクセスマトリクス"D"を使わなくてはいけません。 RSBACには特別なアクセスマトリクスがないので、標準のUNIXのルールを利用します。

さらに以下の追加決定ルールがあります(主要RSBACドキュメントより):

  1. ss-property: x = r または x = w の場合、SiはOjを上書きします(xは読み取り権限を含みます)。
  2. *-property:Siは信頼されている、または
    1. mode = a の場合、OjはSiの現在のレベルを上書きする
    2. mode = w の場合、OjのレベルはSiの現在のレベルと同等
    3. mode = r の場合、Siの現在のレベルはOjのレベルを上書きする
  3. ds-property: x is in cell Mi,j of matrix M of authorized accesses

これはとても難解なモデルに見えると思います。 実際、殆どのプログラムは正しく動作しないでしょう。 何をしたいのかを完璧に理解しているときだけ、これを利用することをお勧めします。

練習問題

MACファイルとユーザ属性を見てみましょう。 "test"ユーザ としてログインします。 /tmp/mactest ファイルを作成し、セキュリティオフィサーとしてログインをして 主要管理プログラムのrsbac_menuを起動します。 "File/Dir Attributes menu" に行きます。 /tmp/mactest ファイルを選択します。 MACファイル属性は以下のようにします：

MAC security level
2に設定します。
MAC categories
触らないでください。
MAC trusted for user
特例: ユーザのセキュリティレベルに関わらず、ファイルはユーザを信頼する。実行可能なファイルだけに適用します。

さて、ユーザ"test"でファイルを開いてみましょう(例えば cat コマンドを使って)。 通常のUNIX権限で許可されたアクセスであるにも関わらず、セキュリティシステムはこのアクセスを拒否します。 このファイルへのアクセスはもっと高いセキュリティレベルが必要です。 rsbac_menu を起動し、"User Attributes: Go to user attribute menu" へ移動します。 おや、ユーザには大量の権限があります。 ユーザ"test"を選択します。２つの項目についてチェックをする必要があります：

Security Level
ユーザのレベルがドキュメントのレベルより高い場合、それを読み取ることができます。２にセットします。
MAC Categories
ユーザカテゴリのセットです。

これで、ユーザ"test"はファイル"mactest"を開けるようになりました。

注意:

MACはプロセスに対して現在のセキュリティレベルをより高いものに変更することは許可しません。 そのため、もしユーザー"Peter"がレベル"0"を、ユーザ"John"がレベル"2"を持っていた場合、 PeterのプロセスはUIDをJohnのものに変更はできません。 これがrootが最大のセキュリティレベルを持っている主な理由です。

開発者への練習問題:

rootのセキュリティレベルに付随する問題を解決しなさい。 一つの方法は(RC enforced role のように)新しく"Enforced MAC security level"属性をファイルに 追加することかもしれません。

ACLモジュール

もうこれで十分に理解ができましたか？...まだですか？ では、ACLに行きましょう。 それぞれのファイルは１つの権限ベクトル(wrxwrxwrx)を持っています。 ベクトルを使う事で、所有者、ユーザのグループ、そして"その他"にアクセス権限を割り当てる事ができます。 しかし、私達はそれぞれのユーザに対して権限を割り当てたいのです。 例えば、user1には(wr-)、user2には(w-x)、そしてgroup1には(--x)というように。 そこで、権限リストが必要になります - アクセスコントロールリスト(ACL)です。 このような理由でACLモジュールを含めたのです。 これにより標準のUNIXにおける権限を拡張します。

練習問題： /tmp/acltest ディレクトリを作成して、 rsbac_menu プログラムを起動し、 file rights メニューに行ってください、次に "ACL Menu: Go to ACL menu" へ... 権限はどこでしょう？ 大丈夫、 "Change mask" を押してください、すると...

ふぅ...これで全部です。 それぞれの項目を有効／無効にできますが、今回は１つだけをテストしてみましょう。

/tmp/acltest ディレクトリのCHDIR権限を無効にします。 さぁ、誰もこのディレクトリに移動できません。 デフォルトのACLエントリの設定(general mask)を如何様にも変更できますが、それに関わらず 特定のユーザやグループや役割について新しく(ACL エントリを)追加できます。 (役割については"RCモジュール"の章を見てください)

"Add ACL Entry:Add group, role or user entry" の項目を選ぶとユーザを追加するように言われます。 リストからユーザを選択します(例えばユーザ"tttt")。 これでこのユーザに対してマスクを変更できます。 このマスクを選んでベクタの全ての権限を有効にします。 結果を見てみましょう。

ユーザ"tttt"だけがこの /tmp/acltest ディレクトリに移動できます。 (セキュリティオフィサーもこのディレクトリに移動できますが、 この動作は通常のUNIX権限によって制限できます！)

ユーザのグループ(ACLグループ)とRC権限にエントリを追加する事もできます。 が、まずRCの説明を先に読む必要があります。

注意

もしあるファイルのACLマスクから全てのユーザの全ての権限を削除したとしても、 セキュリティオフィサーはファイルに対してのアクセス権を持っています。 これはマスク内の"スーパーバイザー"権限によります。 /tmp/acltest のマスクから"スーパーバイザー"を削除することもある条件下では可能です： カーネルの設定で有効にしていて、そのファイルに対して"スーパーバイザー"権限を有している 一般ユーザである場合

練習問題

ACLにあるもう１つの興味深い機能は継承です。 ユーザ、ファイル、その他などのターゲットの幾つかのタイプの:DEFAULT:ACL権限を変更できます。 試してください。

注意。もしセキュリティオフィサーのACL権限のいくつかを削除した場合、 ACLの設定を変更できる可能性を全て失う事があります。

RC モジュール

演劇は好きですか？...ですよね？ だったら役割の考え方を理解するのは簡単になります。 そうでない場合は、以下の文章を読まなくてはいけません。

最初に、キーワードは「ターゲット」と「リクエスト」です。

サブジェクトはターゲットへのアクセスリクエストを作成します。 リクエストは同じACL権限(CHDIR, APPEND_OPEN, ...)を持っています。 ターゲットは以下のようなものです: FILE, DIR, DEV, IPC (セマフォ、メッセージキュー、パイプ...), SCD(System Control Data - 例えばポート番号、カーネルログ等...), USER, PROCESS, NONE(空のターゲット), FD(ファイルディスクリプタ(file descriptor)、 FILE and DIR together)

それぞれターゲットはタイプを持っています。 デフォルトのタイプ(System FD, Security FD等)を使うか新しく作ることができます。

「役割」はサブジェクトのクラスです。 役割は定義されたターゲットと他の役割に対して、このクラスの権限を定義します。

以下が一般的な「役割」のパラメータです：

Name
役割の名前
Role Comp
List of the roles this role can switch without change owner.
Admin Roles
List of the roles this role can administrate (change parameters).
Assign Roles
List of the roles this role can assign to users and processes (using administration utilities).
Type comp FD
ACL permissions of this role for all types of target FD...
Type comp DEV
same, permissions for target DEV.
Type comp Process
same, permissions for target Process.
Type comp IPC
same, permissions for target IPC.
Type comp SCD
same, permissions for target SCD.
Admin Type
Type of role. You can also use the first four parameters (RC separation of duty facility) instead of this. Type may be : General User, System Admin or Role Admin.
Default FD Create Type
Type of target or inherit from ...
Default Process Create Type
付記なし
Default Process Chown Type
付記なし
Default Process Execute Type
付記なし
Default IPC Create Type
付記なし

難しいですか？そうですね、難しいでしょうが、同時にとても強力でもあります。 柔軟な設定をして素晴らしい結果を納めることが可能です。

例えば、この設定の後、管理者はユーザを追加／削除できますが、 /etc/passwd や /etc/shadow のようなファイルを手動で編集できなくなります。 これはWebサイトに非常に有用ではないでしょうか。 そのため、たとえ侵入者がroot権限を取得したとしても、最初からあるWebページを削除できません。 Apacheだけがこのページを編集できるのです。

練習問題

まず最初に、新しいターゲットタイプを作成します - Passwd FD です。 "RC Types" メニューを使って作成します。 次に新しい役割 "Admin Passwd" を作成します。 "RC Roles" メニューに行き、( "Rolelist: Choose role from list" メニューを利用して) 役割として "System Administrator" を選択し、新しい役割にコピーします ( メニューから "Copy Role (New Role)" の項目を使います)。 新しい役割の名前を "Admin Passwd" へ変更しましょう。 ターゲット "Passwd FD"に対するこの役割のACL権限を変更します (全ての権限をセットします、他の役割はデフォルトでこのターゲットに対して何の権限もありません)。 このターゲットの読み取り権限を役割"System Admin"に追加します。 (読み取りのみ(read-only)であって読み書き(read-write)ではありません！)

さて、モデルの準備はできました。 これを実際のオブジェクトに適用してみましょう。 注意してください、システムへのアクセス権限を失う可能性があります。 仮想コンソールからログインしておき、もう一つの仮想コンソールを利用して設定を行うのは良い考えです。

rsbac_menu を起動します。 ファイル属性メニューに移動し、パラメータを探します:

/etc/passwd ファイルを選択し、値を Passwd FD にセットします。 これでroot(System Admin)はこのファイルの読み取り権限(read-only access)を持つようになりました。 ここでlogoutしないでください！

/bin/login ファイルを選択肢、以下の属性を探します：

値を "Admin Passwd" にセットします。 これでloginコマンドは/etc/passwdへのフルアクセス権限を持つようになりました。

useradd プログラムと userdel プログラムにもフルアクセス権限を与えることができます。 これでプログラムには全権限を与えることになりますが、rootはファイルを読み取ることしかできません。 システムはRSBACによって保護されています。

他の興味深いRSBACモジュール

FFモジュール

もう一つの興味深いRSBACモジュールがあります - File Flags です。 このモジュールを使うことで簡単にディレクトリ全体に権限を与えることができます。 例えば、"read_only"フラグを以下のディレクトリに適用できます：

すると、全てのユーザは必要な場合プログラムを実行できますが、誰もファイルを破壊することはできません。 興味深い機能はファイルフラグの継承(FF inheritance)です。 選択したファイルから "add_inherited"フラグ をオフにすることで継承を削除できます。 ですので、/etc ディレクトリを "read_only" にしつつ /etc/mtab ファイルを書き込み可能にできます。

File flag リスト:

no_execute
このフラグは/homeに適用可能で、ユーザは実行ができなくなります
self compiled programs without signing by secoff..
付記なし
secure_delete
セキュアなファイルの削除を有効にします
write_only
読み取りからファイルを保護します(例えばログファイル)
search_only
ディレクトリに対してのみ有用です
execute_only
付記なし
read_only
付記なし

FFモジュールはとても簡単で強力です。

注意:

kenrelコンフィギュレーションの間に "FF Role Protection" を有効にしたら、 セキュリティオフィサーとしてシステムにログインできません。 FFモジュールはセキュリティオフィサーから管理者へ CHANGE_OWNER することを妨げます。 一般ユーザとしてログインして su コマンドでセキュリティオフィサーへ変更する必要があるでしょう。

付記

"Role Protection"はまだAUTHモジュールが書かれていない古いRSBACバージョンからのものです。 この機能は(AUTHモジュールを除いた)全てのRSBACモジュールが持っており、FFのものと同様に動作します。 しかし、RCは(system_role ではなく)自身の rc_role を使い、コンパイル時に中間の役割 （toかfromかに必ず変更されなければいけない）にセットできます。 デフォルトは０で、General_Userとして事前に定義されています。

この機能は多くの制約があり、未だ本当にセキュアとはいえません。 これがデフォルトの設定がRole Protectionをオフにして、AUTHを使うようにしている理由です。

RSBAC を含んでいるディストリビューション

今まで見て来た事はRSBACが使えるようになっているディストリビューションを利用する事で手軽にできます。 現在、ALT Linux Castle -初めてのRSBACベースのLinuxディストリビューションのβ版があります。 詳細は http://people.altlinux.ru/inger/index-en.html を見てください。

最後に

ここではRSBAC decisionモジュールのうち、幾つかしか取り上げていません。 他のモジュールについては自分自身で確認して、私宛かRSBACメーリングリストに質問をしてください。 私はこの素晴らしいセキュリティシステムについての新しい文章を書いている最中です。 ここで最後に幾つか問題を出しておきましょう:

さぁ、これであなたはRSBACを開発・改良・楽しむことが出来るようになりました、我々に成果を教えてください！

The show must go on...

ロシア語から英語への翻訳は以下が行いました。

英語から日本語への翻訳版の作成(及びそれに付随する変更修正)は やまねひでき が行いました。翻訳に問題がある場合、その旨御連絡ください。

last updated