From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Wed Sep 5 23:30:36 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Wed, 5 Sep 2007 23:30:36 +0900 Subject: [Tomoyo-dev 557] =?iso-2022-jp?b?GyRCOD06XyROPnU2NyRLJEQkJCRGGyhC?= Message-ID: <200709052330.GBH69597.UZPNNPtWPtGESPF@I-love.SAKURA.ne.jp> 　熊猫です。 　８／２４に２回目のＬＫＭＬ投稿を行いましたが、 予想以上に反応が少ない状況です。反応が少ない理由が 真面目にソースコードを読もうとしているためなのか、 AppArmor の議論の繰り返しを嫌って投稿を避けているのか、 夏期休暇中でオフラインなだけなのかが判らない所が苦しいです。 　TOMOYO 1.5 をリリースする前に TOMOYO 2.1 を使って 処理が正しいかどうかを専門家に確認しておきたい箇所があったのですが、 http://lkml.org/lkml/2007/9/5/98 によると （処理が正しいかどうか以前に）受信後にフィルタリングするという方法自体 どうにかできないのかという返事のようです。 すぐに処理が正しいかどうかの議論が始まることは期待できそうに無いので、 もうリリースの準備を始めることにします。 　TOMOYO 1.4.2 のバグフィックスを行ったものを 1.4.3 としてリリースし、 1.4.3 に開発会議やこのｍｌで議論してきた仕様変更を加えたものを 1.5.0 としてリリースしたいと思います。 　パッチ（ ccs-patch-\*.txt ）の作り方は以下のようになります。 カーネル 2.6 系のパッチは 1.4.3 と 1.5.0 で全く同一の内容、 カーネル 2.4 系のパッチは Documentation/Configure.help 以外は 1.4.3 と 1.5.0 で同一の内容になります。 1.4.2 用のパッチと比較して、 1.4.3 および 1.5.0 用のパッチは 以下の点が異なります。 (1) fs/namespace.c に関して if (CheckMountPermission(dev_name, dir_name, type_page, &flags)) return -EPERM; 　という行を if ((retval = CheckMountPermission(dev_name, dir_name, type_page, &flags)) < 0) return retval; 　に変更してください。 (2) net/core/datagram.c に関して #include ブロックの後に以下の行を挿入してください。 /***** TOMOYO Linux start. *****/ #include #include /***** TOMOYO Linux end. *****/ 関数 skb_recv_datagram() の中の、 　skb = skb_dequeue(&sk->sk_receive_queue); という処理の後に 　以下の行を挿入してください。 /***** TOMOYO Linux start. *****/ if ((error = CheckSocketRecvDatagramPermission(sk, skb, flags)) < 0) goto no_packet; /***** TOMOYO Linux end. *****/ (3) net/socket.c に関して 関数 sock_recvmsg() の中の以下の行を削除してください。 /***** TOMOYO Linux start. *****/ if (ret >= 0 && CheckSocketRecvMsgPermission(sock, (struct sockaddr *) msg->msg_name, msg->msg_namelen)) { ret = -EAGAIN; /* Hope less harmful than -EPERM. */ } /***** TOMOYO Linux end. *****/ (4) fs/proc/proc_misc.c に関して printk("Hook version: VERSION DATE\n"); 　のようにパッチのバージョンとパッチの作成日を更新してください。 　1.4.3 および 1.5.0 で修正されるバグは以下の３点です。 (1) CheckMountPermission() が -EPERM ではなく正しいエラーコードを返すようにする。 　これは、 /sbin/init が SELinux がサポートされているカーネルかどうかを調べるために 　selinuxfs のマウントを要求しますが、 SELinux がサポートされていないカーネルの場合 　-EPERM を返してしまっていました。 /etc/selinux/config で SELINUX=enforcing と 　指定されていた場合、 /sbin/init は selinuxfs のマウント要求が -EPERM を返すと 　そこでパニックを起こしてしまうため、システムを起動できなくなるという問題がありました。 　この問題は CheckMountPermission() が -EPERM ではなく -ENODEV を返すことにより 　解消されました。 (2) allow_argv0 ... if if ... という指定を正しく処理できるようにする。 　allow_argv0 の２番目のパラメータとして if という単語を指定し、 　さらに if 節も指定した場合、ポリシーパーサが正しく処理できませんでした。 　この問題は、 FindConditionPart() が最後の if 以降を返せるようにすることで 　解消されました。 (3) read() などでパケットを受信した場合にもパケットフィルタリングが機能するようにする。 　1.4.2 までは UDP パケットおよび RAW パケットを受信するために 　read() システムコールや address フィールドに NULL を指定した recvmsg() システムコールで 　受信した場合、送信元アドレスによるパケットフィルタリングが機能しませんでした。 　また、 MSG_PEEK フラグを指定して recv() システムコールを呼び出した場合、 　パケットフィルタリングを行っても受信キューからは削除されないため、 　MSG_PEEK フラグを指定せずに recv() システムコールを呼び出すまで 　次のパケットを受信キューから取り出せなくなるという問題もあることが判明しました。 　これらの問題は、パケットフィルタリングを行う箇所をもっと低いレイヤーに移動させ、 　パケットフィルタリングにより（ MSG_PEEK フラグが指定されている場合でも） 　受信キューから削除されるように修正することで解消されました。 　また、 1.5.0 では以下のように仕様が変更されます。 (1) カーネルコマンドラインに init= でポリシーローダを指定しないで済むようにする。 　1.4.x までは init=/.init という形式でポリシーローダを明示的に実行させるように 　する必要がありました。しかし、 1.5.0 では /sbin/init の実行が要求された時に 　自動的にポリシーローダを呼び出し、その終了を待って /sbin/init の実行を始めるように 　変更されました。この変更により、 grub の設定ファイルで init= を追加する必要が 　なくなりました。 (2) ポリシーローダのパス名を /.init から /sbin/ccs-init に変更する。 　/ ディレクトリ直下にプログラムを置きたくないという要望に応えるため、 　ポリシーローダを / ディレクトリ直下ではなく /sbin/ ディレクトリ直下に 　置くようにしました。 (3) /proc/ccs/ 以下の配置を見直す。 　1.4.x までは /proc/ccs/ の下に用途毎にディレクトリを作成していましたが、 　1.5.0 ではフラットな配置になりました。 　1.0.x との互換性のために残されていた /proc/ccs/info/mapping を廃止しました。 　/proc/ccs/status は /proc/ccs/profile に名称変更されました。 (4) initializer ディレクティブを廃止する。 　今後は initialize_domain ディレクティブを使ってください。 (5) マウント操作のアクセス許可チェック方法を変更する。 　1.4.x までは「マウントするデバイス」「マウントポイント」「ファイルシステム」 　「強制的に有効化／無効化するマウントオプション」という４要素を用いて 　先頭の３要素が一致したら４要素目を反映してから許可するという形の指定をしていましたが、 　1.5.0 では「マウントするデバイス」「マウントポイント」「ファイルシステム」 　「マウントオプション」の４要素を用いて全要素が一致した場合のみ許可するという 　形の指定に変更されました。 　そのため、例えば「 /tmp/ に tmpfs をマウントする場合には自動的に noexec オプションを 　有効にした上で許可する」という指定は、「 /tmp/ に tmpfs を noexec オプションを指定して 　マウントする場合だけ許可する」という指定に置き換わります。 (6) ツールのパス名を /root/ccstools/ から /usr/lib/ccs/ に変更する。 　/ パーティションに置くファイルの数を最小限にしたいという要望に応えるため、 　ポリシーローダである /sbin/ccs-init 以外のツールは 　/root/ccstools/ ではなく /usr/lib/ccs/ ディレクトリに置くようにしました。 (7) /etc/ccs/ 以下の配置を見直す。 　1.4.x まではポリシーファイルの拡張子は .txt でしたが、 　1.5.0 では .conf に変更されました。 　/etc/ccs/status.txt は /etc/ccs/profile.conf に名称変更されました。 (8) ポリシーエディタでカラー表示ができるようにする。 　1.5.0 では editpolicy に行単位で色が付きました。 　環境変数で色の指定が行えるようになると良いかもしれませんね。 (9) ポリシーエディタで冗長なアクセス許可を検出できるようにする。 　まだ試験的な機能ですが、Domain Policy Editor の画面で O キーを押すと 　カーソル行で指定されたアクセス許可に包含されるアクセス許可に 　& マークが表示されるようになりました。この機能を使うと、 　冗長なアクセス許可を効率よく削除していくことができます。 (10) loadpolicy が標準入力からの読み込みをサポートするようにする。 　主に TOMOYO GUI で使うことを前提とした仕様変更ですが、 　ポリシーを /etc/ccs/ ディレクトリからではなく標準入力から 　読み込めるようになりました。 　なお、 TOMOYO 2.1.0 では /proc/ccs/ が /proc/tomoyo/ に、 /etc/ccs/ が /etc/tomoyo/ に、 /sbin/ccs-init が /sbin/tomoyo-init に なっているという点を除いて TOMOYO 1.5.x と同様であり、 TOMOYO 1.5.x と TOMOYO 2.1.x で同じツールを使えます。 ドキュメントは以下の場所で閲覧可能です。 http://tomoyo.sourceforge.jp/ja/1.5.x/ http://tomoyo.sourceforge.jp/ja/2.1.x/ From yocto1 ＠ gmail.com Fri Sep 7 03:36:20 2007 From: yocto1 ＠ gmail.com (yocto) Date: Fri, 7 Sep 2007 03:36:20 +0900 Subject: [Tomoyo-dev 558] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwlKCVHJSMlPyRLPydJVSQxGyhC?= In-Reply-To: <8f3c749a0708130758y4d4c74c6r4badf9ab81953365@mail.gmail.com> References: <200707072336.FIB66431.PtSPEtPWNPNFGZU@I-love.SAKURA.ne.jp> <8f3c749a0707090718h7c69f4d9jaae4231f11672143@mail.gmail.com> <8f3c749a0707110720m637f1915w766ede05fd3330b7@mail.gmail.com> <200708102149.FCI21819.tZPtUNPNGPWSFPE@I-love.SAKURA.ne.jp> <8f3c749a0708110900p279e183dr9d93d2a345fac64d@mail.gmail.com> <200708120305.FEE57143.PEStFtUWNPGPZNP@I-love.SAKURA.ne.jp> <8f3c749a0708130758y4d4c74c6r4badf9ab81953365@mail.gmail.com> Message-ID: <8f3c749a0709061136p23197054oc7fa7f03cd4a9fa5@mail.gmail.com> クスノです。 お久しぶりです、やっと少し時間がとれたので、作ってみました。 ・環境変数名 EDITPOLICY_COLORS ・指定方法 環境変数名=指定箇所=前景色背景色:指定箇所=前景色背景色:〜 EDITPOLICY_COLORS=DOMAIN_HEAD=02:DOMAIN_CURSOR=02:〜 ・指定箇所 Domain Transition Editorのヘッダ部 DOMAIN_HEAD Domain Transition Editorのカーソル行 DOMAIN_CURSOR System Policy Editorのヘッダ部 SYSTEM_HEAD System Policy Editorのカーソル行 SYSTEM_CURSOR Exception Policy Editorのヘッダ部 EXCEPTION_HEAD Exception Policy Editorのカーソル行 EXCEPTION_CURSOR Domain Policy Editorのヘッダ部 ACL_HEAD Domain Policy Editorのカーソル行 ACL_CURSOR ・指定する色番号 BLACK 0 RED 1 GREEN 2 YELLOW 3 BLUE 4 MAGENTA 5 CYAN 6 WHITE 7 ・設定例（デフォルト設定） EDITPOLICY_COLORS=DOMAIN_HEAD=02:DOMAIN_CURSOR=02:SYSTEM_HEAD=74:SYSTEM_CURSOR=74:EXCEPTION_HEAD=06:EXCEPTION_CURSOR=06:ACL_HEAD=03:ACL_CURSOR=03 ＃指定方法が間違っていると、デフォルト設定となります。 07/08/13 に yocto さんは書きました: > クスノです。 > > 07/08/12 に Tetsuo Handa さんは書きました: > > 熊猫です。 > > > > > editpolicy.cをcommitしました。 > > > （Makefileは、commitしてません） > > ありがとうございます。 > > > > ~/.editpolicyrc みたいな設定ファイルを使って > > 自由に色指定ができるようになると良いかもしれませんね。 > > あるいは環境変数のほうが手間が掛からないかな？ > > そうですね、環境変数なら簡単そうですね。 > 設定ファイルなら、キー割り当て等他にもないと > ちょっと寂しい感じです。 > -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: addcolor-env.patch 型: application/octet-stream サイズ: 2632 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/attachments/20070907/67e53543/attachment.obj From from-tomoyo-dev ＠ i-love.sakura.ne.jp Fri Sep 7 09:15:48 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Fri, 07 Sep 2007 09:15:48 +0900 Subject: [Tomoyo-dev 559] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwlKCVHJSMlPyRLPydJVSQxGyhC?= In-Reply-To: <8f3c749a0709061136p23197054oc7fa7f03cd4a9fa5@mail.gmail.com> References: <200707072336.FIB66431.PtSPEtPWNPNFGZU@I-love.SAKURA.ne.jp> <8f3c749a0707090718h7c69f4d9jaae4231f11672143@mail.gmail.com> <8f3c749a0707110720m637f1915w766ede05fd3330b7@mail.gmail.com> <200708102149.FCI21819.tZPtUNPNGPWSFPE@I-love.SAKURA.ne.jp> <8f3c749a0708110900p279e183dr9d93d2a345fac64d@mail.gmail.com> <200708120305.FEE57143.PEStFtUWNPGPZNP@I-love.SAKURA.ne.jp> <8f3c749a0708130758y4d4c74c6r4badf9ab81953365@mail.gmail.com> <8f3c749a0709061136p23197054oc7fa7f03cd4a9fa5@mail.gmail.com> Message-ID: <200709070015.l870Fmsg057826@www262.sakura.ne.jp> 　熊猫です。 > お久しぶりです、やっと少し時間がとれたので、作ってみました。 ありがとうございます。 > ＃指定方法が間違っていると、デフォルト設定となります。 env が '\0' を超えていないかのチェックが抜けていたので 以下のように修正したものを利用させていただくことにします。 static void getColorEnv(char *env) { int i, len; char *p; short color; for (i = 0; color_env[i].name != NULL; i++) { p = color_env[i].name; len = strlen(p); if (strncmp(p, env, len)) continue; env += len; if (strlen(env) != 2) break; color = (*env++) - '0'; // foreground color if (0 <= color && color <= 7) color_env[i].fore = color; color = (*env) - '0'; // background color if (0 <= color && color <= 7) color_env[i].back = color; break; } } From yocto1 ＠ gmail.com Fri Sep 7 17:47:03 2007 From: yocto1 ＠ gmail.com (yocto) Date: Fri, 7 Sep 2007 17:47:03 +0900 Subject: [Tomoyo-dev 560] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwlKCVHJSMlPyRLPydJVSQxGyhC?= In-Reply-To: <200709070015.l870Fmsg057826@www262.sakura.ne.jp> References: <200707072336.FIB66431.PtSPEtPWNPNFGZU@I-love.SAKURA.ne.jp> <8f3c749a0707090718h7c69f4d9jaae4231f11672143@mail.gmail.com> <8f3c749a0707110720m637f1915w766ede05fd3330b7@mail.gmail.com> <200708102149.FCI21819.tZPtUNPNGPWSFPE@I-love.SAKURA.ne.jp> <8f3c749a0708110900p279e183dr9d93d2a345fac64d@mail.gmail.com> <200708120305.FEE57143.PEStFtUWNPGPZNP@I-love.SAKURA.ne.jp> <8f3c749a0708130758y4d4c74c6r4badf9ab81953365@mail.gmail.com> <8f3c749a0709061136p23197054oc7fa7f03cd4a9fa5@mail.gmail.com> <200709070015.l870Fmsg057826@www262.sakura.ne.jp> Message-ID: <8f3c749a0709070147n27679959wd47977c7799462d6@mail.gmail.com> クスノです。 いつもすみません、うぅ、このバグは恥ずかしい... 07/09/07 に from-tomoyo-dev ＠ i-love.sakura.ne.jp さんは書きました: > 　熊猫です。 > > > お久しぶりです、やっと少し時間がとれたので、作ってみました。 > ありがとうございます。 > > > ＃指定方法が間違っていると、デフォルト設定となります。 > env が '\0' を超えていないかのチェックが抜けていたので > 以下のように修正したものを利用させていただくことにします。 > > static void getColorEnv(char *env) > { > int i, len; > char *p; > short color; > > for (i = 0; color_env[i].name != NULL; i++) { > p = color_env[i].name; > len = strlen(p); > if (strncmp(p, env, len)) continue; > env += len; > if (strlen(env) != 2) break; > > color = (*env++) - '0'; // foreground color > if (0 <= color && color <= 7) > color_env[i].fore = color; > > color = (*env) - '0'; // background color > if (0 <= color && color <= 7) > color_env[i].back = color; > > break; > } > } > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > From from-tomoyo-dev ＠ i-love.sakura.ne.jp Mon Sep 10 12:55:27 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Mon, 10 Sep 2007 12:55:27 +0900 Subject: [Tomoyo-dev 561] =?iso-2022-jp?b?GyRCJTclJyVrJTMhPCVJJEskaCRrOTY3YiRyPHUkMU4uGyhC?= =?iso-2022-jp?b?GyRCJDk1IUc9JEskRCQkJEYbKEI=?= Message-ID: <200709100355.l8A3tRPH056716@www262.sakura.ne.jp> 　熊猫です。 　新機能についてのコメント募集です。 　強制アクセス制御を使えば、バッファオーバーフローに シェルコード（と呼ばれる悪意あるプログラム）を流し込んで /bin/sh を起動されてしまうことを防止することができます。 　しかし、シェルコードが無限ループの中で /bin/sh の実行を要求した場合、 （ /bin/sh の実行に成功すれば無限ループは終了するのですが） /bin/sh の実行を拒否したことで無限ループが終了しなくなってしまうため、 ＣＰＵ使用率１００％の状態がずっと続いてしまうという副作用が生じてしまいます。 　そこで、 /bin/sh の実行を拒否する代わりに何か別のプログラムを実行することにより 攻撃を受け流すことができないかと（先週の金曜日にあったＢｏＦに参加して）思いました。 試作してみたところ、技術的には実現できることが判りました。 やっていることは、ファイルの先頭が #! で始まるプログラムを実行する場合に fs/binfmt_script.c で定義されている load_script() が行う処理とほとんど同じです。 ----- パッチ始まり ----- Index: fs/tomoyo_domain.c =================================================================== --- fs/tomoyo_domain.c (revision 454) +++ fs/tomoyo_domain.c (working copy) @@ -674,7 +674,7 @@ return NULL; } -static int FindNextDomain(struct linux_binprm *bprm, struct domain_info **next_domain) +static int FindNextDomain(struct linux_binprm *bprm, struct domain_info **next_domain, const int do_perm_check) { /* This function assumes that the size of buffer returned by realpath() = CCS_MAX_PATHNAME_LEN. */ struct domain_info *old_domain = current->domain_info, *domain = NULL; @@ -713,6 +713,8 @@ else l.name = old_domain_name; fill_path_info(&l); + if (!do_perm_check) goto ok; + /* Check 'alias' directive. */ if (pathcmp(&r, &s)) { struct alias_entry *ptr; @@ -762,6 +764,7 @@ /* Check execute permission. */ if ((retval = CheckExecPerm(&r, filp)) < 0) goto out; + ok: ; /* Allocate memory for calcurating domain name. */ retval = -ENOMEM; if ((new_domain_name = ccs_alloc(CCS_MAX_PATHNAME_LEN + 16)) == NULL) goto out; @@ -806,16 +809,65 @@ #endif +static int try_alt_exec(struct linux_binprm *bprm, char *alt_exec) +{ + struct file *filp; + int retval; + char *domainname = (char *) current->domain_info->domainname->name; /* Will not modified. */ + allow_write_access(bprm->file); + fput(bprm->file); + bprm->file = NULL; + retval = remove_arg_zero(bprm); + if (retval) { + printk("remove_arg_zero(bprm) = %d\n", retval); + return retval; + } + retval = copy_strings_kernel(1, &bprm->interp, bprm); + if (retval < 0) { + printk("copy_strings_kernel(1, &bprm->interp, bprm) = %d\n", retval); + return retval; + } + bprm->argc++; + retval = copy_strings_kernel(1, &domainname, bprm); + if (retval < 0) { + printk("copy_strings_kernel(1, &domainname, bprm) = %d\n", retval); + return retval; + } + bprm->argc++; + retval = copy_strings_kernel(1, &alt_exec, bprm); + if (retval < 0) { + printk("copy_strings_kernel(1, &alt_exec, bprm) = %d\n", retval); + return retval; + } + bprm->argc++; + bprm->interp = alt_exec; + filp = open_exec(alt_exec); + if (IS_ERR(filp)) { + printk("open_exec(alt_exec) = %ld\n", PTR_ERR(filp)); + return PTR_ERR(filp); + } + bprm->file= filp; + bprm->filename = alt_exec; + retval = prepare_binprm(bprm); + if (retval < 0) printk("prepare_binprm(bprm) = %d\n", retval); + return retval; +} + int search_binary_handler_with_transition(struct linux_binprm *bprm, struct pt_regs *regs) { struct domain_info *next_domain = NULL, *prev_domain = current->domain_info; int retval; + char alt_exec[128]; + strcpy(alt_exec, "/bin/logit"); #if defined(CONFIG_SAKURA) || defined(CONFIG_TOMOYO) extern void CCS_LoadPolicy(const char *filename); CCS_LoadPolicy(bprm->filename); #endif #if defined(CONFIG_TOMOYO) - retval = FindNextDomain(bprm, &next_domain); + retval = FindNextDomain(bprm, &next_domain, 1); + if (retval == -EPERM) { + if (try_alt_exec(bprm, alt_exec) >= 0) retval = FindNextDomain(bprm, &next_domain, 0); + } #else retval = 0; next_domain = prev_domain; #endif ----- パッチ終わり ----- 　上記のパッチでは全てのドメインに対してプログラムの実行が拒否された場合に /bin/logit というプログラムを 実行するようにハードコーディングされていますが、実際にはプロファイル単位で /bin/logit 実行するかどうかを 指定できるようにして、実行するプログラムもポリシーファイルで指定するようにします。 /bin/logit の内容は任意で、例えば以下のような内容でも構いません。 ----- /bin/logit の例始まり ----- #! /bin/sh echo "DOMAIN=" $1 shift echo "You don't have permission to call ""$@" env exit 1 ----- /bin/logit の例終わり ----- 　上記のようなプログラムを利用して、「 touch /etc/f* 」という操作をしようとして /usr/bin/touch コマンドの実行が拒否された場合、以下のような情報を取得することができるようになります。 ----- /bin/logit から得られた情報 ----- DOMAIN= /sbin/getty /bin/login /bin/bash You don't have permission to call /usr/bin/touch /etc/fdmount.conf /etc/fonts /etc/fstab /etc/fstab~ HZ=100 TERM=linux SHELL=/bin/bash HUSHLOGIN=FALSE USER=root PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/root/ccstools MAIL=/var/mail/root PWD=/root LANG=C HOME=/root SHLVL=2 LANGUAGE=ja_JP:ja:en_GB:en LOGNAME=root _=/usr/bin/env ----- /bin/logit から得られた情報 ----- 　このように、 /proc/ccs/reject_log から得られる「 /bin/touch というコマンドの実行が拒否された」という 情報だけではなく、「 /bin/touch というコマンドに指定したコマンドラインパラメータや環境変数など」の情報も 取得できるという利点があります。 　また、 /bin/logit の中からメールを送るようにしたり、クライアントのＩＰアドレスなどを取得して ファイアウォールのルールを変更したり攻撃元の情報を他のホストと共有したりする用途にも使えます。 普段はサービスを提供するサーバとして動作していながら、 シェルコードを注ぎ込まれた時だけ攻撃内容を記録するセンサーとして動作します。 シェルコード内の無限ループから /bin/sh の実行が要求された場合にも、 /bin/true 等の無害なプログラムを実行するなり情報収集するなりしてプロセスが終了するので、 ＣＰＵ使用率１００％の状態がずっと続いてしまうという副作用を回避できます。 　ユーザが要求したプログラムとは異なるプログラムが実行されるというのを気持ち悪く思う人が多いようですが、 管理者が「〜〜の場合には・・・を代わりに実行する」ようにポリシーで指示した上で上記のように動作するのであれば、 何かの役に立つのではないかと思います。 http://marc.info/?l=linux-security-module&m=118916470210794&w=2 　皆さんはどう思われますか？ From nez ＠ samba.gr.jp Mon Sep 10 13:38:06 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Mon, 10 Sep 2007 13:38:06 +0900 (JST) Subject: [Tomoyo-dev 562] Re: =?iso-2022-jp?b?GyRCJTclJyVrJTMhPCVJJEskaCRrOTY3YiRyPHUbKEI=?= =?iso-2022-jp?b?GyRCJDFOLiQ5NSFHPSRLJEQkJCRGGyhC?= In-Reply-To: <200709100355.l8A3tRPH056716@www262.sakura.ne.jp> References: <200709100355.l8A3tRPH056716@www262.sakura.ne.jp> Message-ID: <7408.163.135.10.35.1189399086.squirrel@webmail.knlab.com> $B:,DE$G$9!#(B On 2007$BG/(B 9$B7n(B 10$BF|(B ($B7n(B) 12:55, from-tomoyo-dev ＠ i-love.sakura.ne.jp wrote: > $B!!%f!<%6$,MW5a$7$?%W%m%0%i%`$H$O0[$J$k%W%m%0%i%`$, $B0-$/;W$&?M$,B?$$$h$&$G$9$,!"(B > $B4IM}l9g$K$O!&!&!&$rBe$o$j$Ke(B > $B$G>e5-$N$h$&$KF0:n$9$k$N$G$"$l$P!"(B > $B2?$+$NLr$KN)$D$N$G$O$J$$$+$H;W$$$^$9!#(B $B$(!<$C$H!"5$;}$A$,0-$$!&!&!&$H$$$&$N$O(I"$B5$J,!W$NLdBj$G$O$J$/!"$3$N$h$&$J(B $BI{:nMQ$rF3F~$9$k$H$$$&$N$O!"(BTOMOYO$B$r(BSecure OS$B$G$J$$$b$N$H$7$F(I"$B1x$9(I#$B$3$H$K(B $B$J$k$H;W$&$N$G$9$,$$$+$,$G$7$g$&$+!)(B $B$J$H$i$79g$o$;$F(B $B=M!9$H/$J$$%7%9%F%`%3!<%k$d%7%s%W%k$J%9%H%j!<%`(B $BF~=PNO$J$I!V%r%l%r%l$J5!G=$rF3F~$7$?$$M6OG!W$H$N ＠ o$$$NNr;K$G$b$"$j$^$9!#(B $B%+!<%M%k$N5!G=$O%7%s%W%k$G$"$l$P$"$k$[$I!"I,MWIT2D7g$N$b$N0J30$r6K8B$^$G(B $B$=$.Mn$H$;$P$=$.Mn$H$9$[$I%+!<%M%k<+BN$N?.Mj ＠ -$H7rA4 ＠ -!"7xO4 ＠ -$,J]>c$5$l$^$9!#(B $B$3$NE@$+$i8@$C$F!"%+!<%M%k$Ko$K$h$/$o$+$k$N$G$9$,!"%3%a%s%H$r5a$a$i$l(B $B$F$$$k(B $B!t;~E@$G!VI,MWIT2D7g$J5!G=!W$H$O$$$($J$$$H;W$&$N$G!"(BTOMOYO$B$N%a%$%s%i%$%s$X$N(B $B!tF3F~$O$4<+J,$G5Q2<$5$l$F$$$k$H;W$$$^$9$,$$$+$,$G$7$g$&$+!)(B -- ------ $B:,DE(B $B8&2p(B $BF|K\(BSamba$B%f!<%62q(B/NTT$B%G!<%?@hC<5;=Q!J3t!K(B Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11$B%;%-%e%j%F%#%5%$%H!'(Bhttp://www.famm.jp/wireless $B"(!V(BSELinux$B%7%9%F%`4IM}!=%;%-%e%"(BOS$B$N4pAC$H1?MQ!W(B http://www.oreilly.co.jp/books/4873112257/ $B"(!V References: <200709100355.l8A3tRPH056716@www262.sakura.ne.jp> Message-ID: <9d732d950709100216k325a2bd8y92084a3e471b6ce3@mail.gmail.com> 原田です。 07/09/10 に from-tomoyo-dev ＠ i-love.sakura.ne.jp さんは書きました: > 新機能についてのコメント募集です。 > > 強制アクセス制御を使えば、バッファオーバーフローに > シェルコード（と呼ばれる悪意あるプログラム）を流し込んで > /bin/sh を起動されてしまうことを防止することができます。 > > しかし、シェルコードが無限ループの中で /bin/sh の実行を要求した場合、 > （ /bin/sh の実行に成功すれば無限ループは終了するのですが） > /bin/sh の実行を拒否したことで無限ループが終了しなくなってしまうため、 > ＣＰＵ使用率１００％の状態がずっと続いてしまうという副作用が生じてしまいます。 > > そこで、 /bin/sh の実行を拒否する代わりに何か別のプログラムを実行することにより > 攻撃を受け流すことができないかと（先週の金曜日にあったＢｏＦに参加して）思いました。 発案の内容を以下のように理解しました。 ・execveの失敗の際に、ポリシーで定義があれば 　登録されていた別のプログラムを実行する ・そのことにより、exploit攻撃の副作用として 　CPU100%となることを防ぐことができ、 　それ以外の応用も可能である > 試作してみたところ、技術的には実現できることが判りました。 > やっていることは、ファイルの先頭が #! で始まるプログラムを実行する場合に > fs/binfmt_script.c で定義されている load_script() が行う処理とほとんど同じです。 > > ----- パッチ始まり ----- ここでパッチが含まれているのはちょっと変な気がしました。 「こんなに簡単に（少ないパッチ）でできる」という ことかもしれませんが、それは発案の内容の有意性や 機能の採用とは独立だと思うからです。 > ----- パッチ終わり ----- > > 上記のパッチでは全てのドメインに対してプログラムの実行が拒否された場合に /bin/logit というプログラムを > 実行するようにハードコーディングされていますが、実際にはプロファイル単位で /bin/logit 実行するかどうかを > 指定できるようにして、実行するプログラムもポリシーファイルで指定するようにします。 > /bin/logit の内容は任意で、例えば以下のような内容でも構いません。 > > ----- /bin/logit の例始まり ----- > #! /bin/sh > echo "DOMAIN=" $1 > shift > echo "You don't have permission to call ""$@" > env > exit 1 > ----- /bin/logit の例終わり ----- > > 上記のようなプログラムを利用して、「 touch /etc/f* 」という操作をしようとして > /usr/bin/touch コマンドの実行が拒否された場合、以下のような情報を取得することができるようになります。 > > ----- /bin/logit から得られた情報 ----- > DOMAIN= /sbin/getty /bin/login /bin/bash > You don't have permission to call /usr/bin/touch /etc/fdmount.conf /etc/fonts /etc/fstab /etc/fstab~ > HZ=100 > TERM=linux > SHELL=/bin/bash > HUSHLOGIN=FALSE > USER=root > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/root/ccstools > MAIL=/var/mail/root > PWD=/root > LANG=C > HOME=/root > SHLVL=2 > LANGUAGE=ja_JP:ja:en_GB:en > LOGNAME=root > _=/usr/bin/env > ----- /bin/logit から得られた情報 ----- > > このように、 /proc/ccs/reject_log から得られる「 /bin/touch というコマンドの実行が拒否された」という > 情報だけではなく、「 /bin/touch というコマンドに指定したコマンドラインパラメータや環境変数など」の情報も > 取得できるという利点があります。 > また、 /bin/logit の中からメールを送るようにしたり、クライアントのＩＰアドレスなどを取得して > ファイアウォールのルールを変更したり攻撃元の情報を他のホストと共有したりする用途にも使えます。 > 普段はサービスを提供するサーバとして動作していながら、 > シェルコードを注ぎ込まれた時だけ攻撃内容を記録するセンサーとして動作します。 > シェルコード内の無限ループから /bin/sh の実行が要求された場合にも、 > /bin/true 等の無害なプログラムを実行するなり情報収集するなりしてプロセスが終了するので、 > ＣＰＵ使用率１００％の状態がずっと続いてしまうという副作用を回避できます。 > > ユーザが要求したプログラムとは異なるプログラムが実行されるというのを気持ち悪く思う人が多いようですが、 > 管理者が「〜〜の場合には・・・を代わりに実行する」ようにポリシーで指示した上で上記のように動作するのであれば、 > 何かの役に立つのではないかと思います。 > > http://marc.info/?l=linux-security-module&m=118916470210794&w=2 > > 皆さんはどう思われますか？ 私も気持ち悪く感じた一人です。その気持ち悪さがどこから くるのか考えてみました。 ・ひとつには、根津さんが指摘しているようにそのような 　機能を持つことはリファレンスモニターや現在 　セキュアOSとして認識されている範疇を「超える」ことがあります。 　別に超えてはいけないという決まりはありませんが、 　超えてしまうことに「気持ち悪さ」を感じます。 ・万一、代わりに実行させるプログラム自体が有害な場合には、 　大きな影響が出ます。（勿論そうならないよう配慮は 　するでしょうけれども） 　やるにしても、直接execするのではなく、何らかの 　状態フラグとして実現して、それを利用者が利用する形が 　望ましい気がします。 ・「CPU100%を回避する」が最大の狙いと認識していますが、 　それは必ずしも/bin/shを無限ループでexecするだけではないので、 　少なくともそれだけが導入の理由にはならないと思います。 以上です。 -- Toshiharu Harada haradats ＠ gmail.com From haradats ＠ gmail.com Fri Sep 14 19:14:06 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Fri, 14 Sep 2007 19:14:06 +0900 Subject: [Tomoyo-dev 564] Re: =?iso-2022-jp?b?GyRCJTclJyVrJTMhPCVJJEskaCRrOTY3YiRyPHUbKEI=?= =?iso-2022-jp?b?GyRCJDFOLiQ5NSFHPSRLJEQkJCRGGyhC?= In-Reply-To: <9d732d950709100216k325a2bd8y92084a3e471b6ce3@mail.gmail.com> References: <200709100355.l8A3tRPH056716@www262.sakura.ne.jp> <9d732d950709100216k325a2bd8y92084a3e471b6ce3@mail.gmail.com> Message-ID: <9d732d950709140314x1140b0fbp966dc3430ec4e71d@mail.gmail.com> 原田です。 本件について本日、3名（原田、半田、武田）で話をしましたので 情報共有のため投稿します。半田さんの発言の部分は 代筆になりますが、誤っていたら訂正ください。＞半田さん 07/09/10 に Toshiharu Harada さんは書きました: > 原田です。 > > 07/09/10 に from-tomoyo-dev ＠ i-love.sakura.ne.jp > さんは書きました: > > 新機能についてのコメント募集です。 > > > > 強制アクセス制御を使えば、バッファオーバーフローに > > シェルコード（と呼ばれる悪意あるプログラム）を流し込んで > > /bin/sh を起動されてしまうことを防止することができます。 > > > > しかし、シェルコードが無限ループの中で /bin/sh の実行を要求した場合、 > > （ /bin/sh の実行に成功すれば無限ループは終了するのですが） > > /bin/sh の実行を拒否したことで無限ループが終了しなくなってしまうため、 > > ＣＰＵ使用率１００％の状態がずっと続いてしまうという副作用が生じてしまいます。 > > > > そこで、 /bin/sh の実行を拒否する代わりに何か別のプログラムを実行することにより > > 攻撃を受け流すことができないかと（先週の金曜日にあったＢｏＦに参加して）思いました。 > > 発案の内容を以下のように理解しました。 > ・execveの失敗の際に、ポリシーで定義があれば > 登録されていた別のプログラムを実行する > ・そのことにより、exploit攻撃の副作用として > CPU100%となることを防ぐことができ、 > それ以外の応用も可能である > > > 試作してみたところ、技術的には実現できることが判りました。 > > やっていることは、ファイルの先頭が #! で始まるプログラムを実行する場合に > > fs/binfmt_script.c で定義されている load_script() が行う処理とほとんど同じです。 > > > > ----- パッチ始まり ----- > > ここでパッチが含まれているのはちょっと変な気がしました。 > 「こんなに簡単に（少ないパッチ）でできる」という > ことかもしれませんが、それは発案の内容の有意性や > 機能の採用とは独立だと思うからです。 > > > ----- パッチ終わり ----- > > > > 上記のパッチでは全てのドメインに対してプログラムの実行が拒否された場合に /bin/logit というプログラムを > > 実行するようにハードコーディングされていますが、実際にはプロファイル単位で /bin/logit 実行するかどうかを > > 指定できるようにして、実行するプログラムもポリシーファイルで指定するようにします。 > > /bin/logit の内容は任意で、例えば以下のような内容でも構いません。 > > > > ----- /bin/logit の例始まり ----- > > #! /bin/sh > > echo "DOMAIN=" $1 > > shift > > echo "You don't have permission to call ""$@" > > env > > exit 1 > > ----- /bin/logit の例終わり ----- > > > > 上記のようなプログラムを利用して、「 touch /etc/f* 」という操作をしようとして > > /usr/bin/touch コマンドの実行が拒否された場合、以下のような情報を取得することができるようになります。 > > > > ----- /bin/logit から得られた情報 ----- > > DOMAIN= /sbin/getty /bin/login /bin/bash > > You don't have permission to call /usr/bin/touch /etc/fdmount.conf /etc/fonts /etc/fstab /etc/fstab~ > > HZ=100 > > TERM=linux > > SHELL=/bin/bash > > HUSHLOGIN=FALSE > > USER=root > > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/root/ccstools > > MAIL=/var/mail/root > > PWD=/root > > LANG=C > > HOME=/root > > SHLVL=2 > > LANGUAGE=ja_JP:ja:en_GB:en > > LOGNAME=root > > _=/usr/bin/env > > ----- /bin/logit から得られた情報 ----- > > > > このように、 /proc/ccs/reject_log から得られる「 /bin/touch というコマンドの実行が拒否された」という > > 情報だけではなく、「 /bin/touch というコマンドに指定したコマンドラインパラメータや環境変数など」の情報も > > 取得できるという利点があります。 > > また、 /bin/logit の中からメールを送るようにしたり、クライアントのＩＰアドレスなどを取得して > > ファイアウォールのルールを変更したり攻撃元の情報を他のホストと共有したりする用途にも使えます。 > > 普段はサービスを提供するサーバとして動作していながら、 > > シェルコードを注ぎ込まれた時だけ攻撃内容を記録するセンサーとして動作します。 > > シェルコード内の無限ループから /bin/sh の実行が要求された場合にも、 > > /bin/true 等の無害なプログラムを実行するなり情報収集するなりしてプロセスが終了するので、 > > ＣＰＵ使用率１００％の状態がずっと続いてしまうという副作用を回避できます。 > > > > ユーザが要求したプログラムとは異なるプログラムが実行されるというのを気持ち悪く思う人が多いようですが、 > > 管理者が「〜〜の場合には・・・を代わりに実行する」ようにポリシーで指示した上で上記のように動作するのであれば、 > > 何かの役に立つのではないかと思います。 > > > > http://marc.info/?l=linux-security-module&m=118916470210794&w=2 > > > > 皆さんはどう思われますか？ > > 私も気持ち悪く感じた一人です。その気持ち悪さがどこから > くるのか考えてみました。 > > ・ひとつには、根津さんが指摘しているようにそのような > 機能を持つことはリファレンスモニターや現在 > セキュアOSとして認識されている範疇を「超える」ことがあります。 > 別に超えてはいけないという決まりはありませんが、 > 超えてしまうことに「気持ち悪さ」を感じます。 半田： そもそもTOMOYO は TCSEC 等に準拠することを目的として 開発されたものではなく、「セキュリティを強化したＯＳ」ではあっても 「セキュアＯＳ」ではないので（超えても気にすることはない）。 原田： 「気持ち悪い」は有意な判断基準や理由にはならないが、 LKMLを含め提案してもらう際には、既存の概念で 整理、理解できないのは不利に働くことを懸念していた。 > ・万一、代わりに実行させるプログラム自体が有害な場合には、 > 大きな影響が出ます。（勿論そうならないよう配慮は > するでしょうけれども） 半田： 強制アクセス制御が無い世界なら壊滅的な影響を受けるが、 TOMOYO はシステムワイドに強制アクセス制御ができる。 例え代わりに実行させるプログラム自体が有害であったとしても、 そのプログラムは何れかのドメインに属しており、強制アクセス制御が 有効な状態を維持できる。 原田： それは理解しているが、被害を回避できることが保証されるのは、 「強制アクセス制御が有効」なだけでなく、適切に設定されている 場合という条件がつく。その条件は満たされていることを 仮定すべきではなく、リスクを可能な限り回避するという 考え方からはやはり望ましくないと思う。 > やるにしても、直接execするのではなく、何らかの > 状態フラグとして実現して、それを利用者が利用する形が > 望ましい気がします。 半田： 状態フラグを扱うには /proc/ccs/ インタフェースやポリシー構文／パーサの 仕様変更およびユーザランドで動くデーモンプロセスの新規作成が 必要になるため、それこそ sleep や alt_exec の何倍もの大改造が必要に なる。 必要最小限のトリガ機能だけをカーネル内に搭載し、後の処理を利用者に 任せるのは、状態フラグをデーモンで監視することよりもずっと利用者に とって利用しやすい方法。 原田： メールで書いた状態フラグはおおがかりな仕組みではなく、 単純にはエラーコードの追加を想定しており、カーネル内のフラグの 新設およびそのデーモンの監視は考えていない。 > ・「CPU100%を回避する」が最大の狙いと認識していますが、 > それは必ずしも/bin/shを無限ループでexecするだけではないので、 > 少なくともそれだけが導入の理由にはならないと思います。 原田： 仮に提案を採用してexecの無限ループによる呼び出しによる CPU100%を回避することができたとして、無限ループによる 呼び出し（攻撃）による攻撃はexecに限らない。 さらに言えばDOS攻撃はMACでは防げないから、 execの失敗のみ対処するのはどうかと思う。 半田： alt_exec は使い勝手向上のための新機能ではなく、 全ての強制アクセス制御の実装に於いて生じる副作用（バグ）を 軽減するためのバグフィックスであり、是非導入すべき。 mlには書いていないがsleepという機能も考えている。 原田： sleepについては、まだ説明を聞いていないがtomoyo-devで 説明して欲しい。alt_execやsleepについては 何が何でも採用しないというわけではないが、 tomoyo-devでの同意は必要。 （ここにて議論は時間切れ） ということで、皆さんの意見を聞き議論したいので、 メールしました。発言されていない方も意見を お聞かせください。なお、ここで提案されている内容は メインライン提案ではなくTOMOYOの1系が対象です。 念のため。 -- Toshiharu Harada haradats ＠ gmail.com From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Sep 15 10:57:44 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 15 Sep 2007 10:57:44 +0900 Subject: [Tomoyo-dev 565] Re: =?iso-2022-jp?b?GyRCJTclJyVrJTMhPCVJJEskaCRrOTY3YiRyPHUbKEI=?= =?iso-2022-jp?b?GyRCJDFOLiQ5NSFHPSRLJEQkJCRGGyhC?= In-Reply-To: <9d732d950709140314x1140b0fbp966dc3430ec4e71d@mail.gmail.com> References: <200709100355.l8A3tRPH056716@www262.sakura.ne.jp> <9d732d950709100216k325a2bd8y92084a3e471b6ce3@mail.gmail.com> <9d732d950709140314x1140b0fbp966dc3430ec4e71d@mail.gmail.com> Message-ID: <200709151057.GFE71712.PEPNPPSUNtFtZGW@I-love.SAKURA.ne.jp> 　熊猫です。 > 原田： > sleepについては、まだ説明を聞いていないがtomoyo-devで > 説明して欲しい。alt_execやsleepについては > 何が何でも採用しないというわけではないが、 > tomoyo-devでの同意は必要。 sleep 機能とは、ポリシー違反を発生させたプロセスに対して、 そのプロセスを一定時間スリープ状態にするというペナルティを与えるものです。 http://marc.info/?l=linux-security-module&m=118916470210794&w=2 のスレッドの中で 登場した tar-baby と呼ばれる機能に似ています。 「ポリシーにより許可されていないプログラムの実行が無限ループの中で要求されてしまうことにより ＣＰＵ使用率が１００％になるのを防ぐ」という目的を達成するには最も単純な対処法です。 しかし、 alt_exec 機能であれば、「Linuxカーネルベース不正侵入検知システム」 （ http://www.selinux.gr.jp/selinux-users-ml/200401.month/261.html http://www.itmedia.co.jp/enterprise/articles/0406/03/news011.html ）みたいに 単純にエラーを返すだけでなく追加のアクションを起こすことができます。 > 原田： > それは理解しているが、被害を回避できることが保証されるのは、 > 「強制アクセス制御が有効」なだけでなく、適切に設定されている > 場合という条件がつく。その条件は満たされていることを > 仮定すべきではなく、リスクを可能な限り回避するという > 考え方からはやはり望ましくないと思う。 だから、デフォルトでは sleep 機能や alt_exec 機能は無効に設定してあり、 1.5.0 に取り込んだとしても 1.4.3 と同じように使えます。 追加のアクションを起こせることのメリットとリスクを理解した上で使えば良い機能なのです。 > 原田： > メールで書いた状態フラグはおおがかりな仕組みではなく、 > 単純にはエラーコードの追加を想定しており、カーネル内のフラグの > 新設およびそのデーモンの監視は考えていない。 仮に、強制アクセス制御のポリシーにより拒否された場合は EPERM ではなく EMACPERMDENIED というエラーを 返すようにした場合、ユーザランドのプログラムは EMACPERMDENIED の場合には特別な対処 （例えばプロセスを強制終了させる）をするように作成されていなければならなくなります。 全てのプログラムがそのような特別な対処をするように作成されているはずが無いですし、 特別な対処を行っているプログラムであっても、（シェルコードにより /bin/sh の実行が要求されているという時点で） 既にバッファオーバーフローにより制御を失っていると考えられます。 エラーコードを追加したとして、そのエラーコードをユーザランドに届けたところで、役に立つとは思えません。 > 原田： > 仮に提案を採用してexecの無限ループによる呼び出しによる > CPU100%を回避することができたとして、無限ループによる > 呼び出し（攻撃）による攻撃はexecに限らない。 > さらに言えばDOS攻撃はMACでは防げないから、 > execの失敗のみ対処するのはどうかと思う。 多くの場合、攻撃者の狙いは 「標的のマシンのＣＰＵ使用率を１００％にすることで正常なサービスを提供できないようにする」ことではなく 「標的のマシンで /bin/sh を実行することで（改ざんや漏洩、踏み台の設置などの）悪事を働く」ことであると 考えられます。（もし、ＣＰＵ使用率を１００％にすることだけが狙いなら、強制アクセス制御は無力です。） しかし、「強制アクセス制御が /bin/sh の実行を拒否したことが原因で標的のマシンのＣＰＵ使用率が １００％になってしまい、正常なサービスが提供できなくなる」ことは 攻撃者の当初の目的を防ぐことができるとしても、管理者にとっては嬉しいことではありません。 だから、最低でも sleep 機能を、できれば alt_exec 機能も 1.5.0 に採用したいのです。 From nez ＠ samba.gr.jp Sat Sep 15 15:38:12 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Sat, 15 Sep 2007 15:38:12 +0900 Subject: [Tomoyo-dev 566] Re: =?iso-2022-jp?b?GyRCJTclJyVrJTMhPCVJJEskaCRrOTY3YiRyPHUbKEI=?= =?iso-2022-jp?b?GyRCJDFOLiQ5NSFHPSRLJEQkJCRGGyhC?= In-Reply-To: <200709151057.GFE71712.PEPNPPSUNtFtZGW@I-love.SAKURA.ne.jp> References: <200709100355.l8A3tRPH056716@www262.sakura.ne.jp> <9d732d950709100216k325a2bd8y92084a3e471b6ce3@mail.gmail.com> <9d732d950709140314x1140b0fbp966dc3430ec4e71d@mail.gmail.com> <200709151057.GFE71712.PEPNPPSUNtFtZGW@I-love.SAKURA.ne.jp> Message-ID: <46EB7DD4.2060309@samba.gr.jp> 根津です。 ＃なんか半田さんが「必要」と思うものは何を言っても入りそうな勢いな ＃感じがするので、議論に意味があるのかちょっと疑問ですが・・・ｗ ひとつ質問があるんですが、ccsの名前のときに「削る」ことに「世界が かわる」ことを理由に拒絶されてましたが、今回の機能をつけ加える ことは半田さんのccsの世界ではどういう扱いになるんでしょうか？ なんでこんな質問をするかというと、半田さんがポリシとしてもつ 世界観が今回の件でわかんなくなったからです。 Tetsuo Handa wrote: > 　熊猫です。 > >> 原田： >> sleepについては、まだ説明を聞いていないがtomoyo-devで >> 説明して欲しい。alt_execやsleepについては >> 何が何でも採用しないというわけではないが、 >> tomoyo-devでの同意は必要。 > sleep 機能とは、ポリシー違反を発生させたプロセスに対して、 > そのプロセスを一定時間スリープ状態にするというペナルティを与えるものです。 > http://marc.info/?l=linux-security-module&m=118916470210794&w=2 のスレッドの中で > 登場した tar-baby と呼ばれる機能に似ています。 > 「ポリシーにより許可されていないプログラムの実行が無限ループの中で要求されてしまうことにより > ＣＰＵ使用率が１００％になるのを防ぐ」という目的を達成するには最も単純な対処法です。 > > しかし、 alt_exec 機能であれば、「Linuxカーネルベース不正侵入検知システム」 > （ http://www.selinux.gr.jp/selinux-users-ml/200401.month/261.html > http://www.itmedia.co.jp/enterprise/articles/0406/03/news011.html ）みたいに > 単純にエラーを返すだけでなく追加のアクションを起こすことができます。 > >> 原田： >> それは理解しているが、被害を回避できることが保証されるのは、 >> 「強制アクセス制御が有効」なだけでなく、適切に設定されている >> 場合という条件がつく。その条件は満たされていることを >> 仮定すべきではなく、リスクを可能な限り回避するという >> 考え方からはやはり望ましくないと思う。 > だから、デフォルトでは sleep 機能や alt_exec 機能は無効に設定してあり、 > 1.5.0 に取り込んだとしても 1.4.3 と同じように使えます。 > 追加のアクションを起こせることのメリットとリスクを理解した上で使えば良い機能なのです。 > >> 原田： >> メールで書いた状態フラグはおおがかりな仕組みではなく、 >> 単純にはエラーコードの追加を想定しており、カーネル内のフラグの >> 新設およびそのデーモンの監視は考えていない。 > 仮に、強制アクセス制御のポリシーにより拒否された場合は EPERM ではなく EMACPERMDENIED というエラーを > 返すようにした場合、ユーザランドのプログラムは EMACPERMDENIED の場合には特別な対処 > （例えばプロセスを強制終了させる）をするように作成されていなければならなくなります。 > 全てのプログラムがそのような特別な対処をするように作成されているはずが無いですし、 > 特別な対処を行っているプログラムであっても、（シェルコードにより /bin/sh の実行が要求されているという時点で） > 既にバッファオーバーフローにより制御を失っていると考えられます。 > エラーコードを追加したとして、そのエラーコードをユーザランドに届けたところで、役に立つとは思えません。 > >> 原田： >> 仮に提案を採用してexecの無限ループによる呼び出しによる >> CPU100%を回避することができたとして、無限ループによる >> 呼び出し（攻撃）による攻撃はexecに限らない。 >> さらに言えばDOS攻撃はMACでは防げないから、 >> execの失敗のみ対処するのはどうかと思う。 > 多くの場合、攻撃者の狙いは > 「標的のマシンのＣＰＵ使用率を１００％にすることで正常なサービスを提供できないようにする」ことではなく > 「標的のマシンで /bin/sh を実行することで（改ざんや漏洩、踏み台の設置などの）悪事を働く」ことであると > 考えられます。（もし、ＣＰＵ使用率を１００％にすることだけが狙いなら、強制アクセス制御は無力です。） > しかし、「強制アクセス制御が /bin/sh の実行を拒否したことが原因で標的のマシンのＣＰＵ使用率が > １００％になってしまい、正常なサービスが提供できなくなる」ことは > 攻撃者の当初の目的を防ぐことができるとしても、管理者にとっては嬉しいことではありません。 > > だから、最低でも sleep 機能を、できれば alt_exec 機能も 1.5.0 に採用したいのです。 > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Sep 15 20:39:49 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 15 Sep 2007 20:39:49 +0900 Subject: [Tomoyo-dev 567] Re: =?iso-2022-jp?b?GyRCJTclJyVrJTMhPCVJJEskaCRrOTY3YiRyPHUbKEI=?= =?iso-2022-jp?b?GyRCJDFOLiQ5NSFHPSRLJEQkJCRGGyhC?= In-Reply-To: <46EB7DD4.2060309@samba.gr.jp> References: <200709100355.l8A3tRPH056716@www262.sakura.ne.jp> <9d732d950709100216k325a2bd8y92084a3e471b6ce3@mail.gmail.com> <9d732d950709140314x1140b0fbp966dc3430ec4e71d@mail.gmail.com> <200709151057.GFE71712.PEPNPPSUNtFtZGW@I-love.SAKURA.ne.jp> <46EB7DD4.2060309@samba.gr.jp> Message-ID: <200709152039.EDE71357.PtGPUSENWZFNtPP@I-love.SAKURA.ne.jp> 　熊猫です。 > ＃なんか半田さんが「必要」と思うものは何を言っても入りそうな勢いな > ＃感じがするので、議論に意味があるのかちょっと疑問ですが・・・ｗ よくご存知で。（＾ｘ＾； 今後起こる事件・事故を予想して行動したり愚痴ったりする動物ですから。 > ひとつ質問があるんですが、ccsの名前のときに「削る」ことに「世界が > かわる」ことを理由に拒絶されてましたが、今回の機能をつけ加える > ことは半田さんのccsの世界ではどういう扱いになるんでしょうか？ え〜っと、今回の機能を付け加えることは CCS の世界とは無関係だと思います。 今までも keep_domain 構文とか initialize_domain 構文とかいろんな機能を 追加してきましたが、 CCS の世界での扱いを考えたことは無いです。 こういう機能があれば管理者にとってより使いやすくなるんじゃないかとか セキュリティ強化に役立つのではないかとかいう予想から生まれているものです。 勘みたいなものなので理論的に説明できないのが難しいところです。 私の中にあるのは、 TOMOYO 1.0 がリリースされる前から存在していた SAKURA: システム全体としてアクセス可否を制御する部分 TOMOYO: ドメイン単位でアクセス可否を制御する部分 SYAORAN: デバイスファイルの改ざん防止を担当する部分 CERBERUS: 不正なログインの防止を担当する部分 YUE: 管理者権限の分割を担当する部分 という棲み分けと、これらが揃って CCS という世界を構成していること、 そして CCS という世界に願いを込めていることだと思います。 だから、今回の sleep 機能や alt_exec 機能が採用されようとされまいと、 CCS の世界での扱いがどうなるのかを心配するものでは無いと考えています。 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Tue Sep 18 12:01:55 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Tue, 18 Sep 2007 12:01:55 +0900 Subject: [Tomoyo-dev 568] =?iso-2022-jp?b?GyRCJTclJyVrJTMhPCVJJEskaCRrOTY3YiRyPHUkMU4uGyhC?= =?iso-2022-jp?b?GyRCJDk1IUc9JEskRCQkJEYbKEI=?= In-Reply-To: <200709100355.l8A3tRPH056716@www262.sakura.ne.jp> References: <200709100355.l8A3tRPH056716@www262.sakura.ne.jp> Message-ID: <200709180301.l8I31tgx052574@www262.sakura.ne.jp> 　熊猫です。 　sleep 機能と alt_exec 機能について TOMOYO Linux 1.5.0 には 含められないことが確定しました。理由は、新機能に該当するので 特許侵害にならないかどうかの調査を行わなければならず、 リリースが何ヶ月という単位で遅くなってしまうことで 現在進行中の案件にも影響が出てしまうためです。 　よって、 TOMOYO Linux 1.5.0 は TOMOYO Linux 1.4.3 と同機能のまま リリースすることになりました。 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Tue Sep 18 12:40:02 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Tue, 18 Sep 2007 12:40:02 +0900 Subject: [Tomoyo-dev 569] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwlKCVHJSMlPyRLPydJVSQxGyhC?= In-Reply-To: <8f3c749a0709070147n27679959wd47977c7799462d6@mail.gmail.com> References: <200707072336.FIB66431.PtSPEtPWNPNFGZU@I-love.SAKURA.ne.jp> <8f3c749a0707090718h7c69f4d9jaae4231f11672143@mail.gmail.com> <8f3c749a0707110720m637f1915w766ede05fd3330b7@mail.gmail.com> <200708102149.FCI21819.tZPtUNPNGPWSFPE@I-love.SAKURA.ne.jp> <8f3c749a0708110900p279e183dr9d93d2a345fac64d@mail.gmail.com> <200708120305.FEE57143.PEStFtUWNPGPZNP@I-love.SAKURA.ne.jp> <8f3c749a0708130758y4d4c74c6r4badf9ab81953365@mail.gmail.com> <8f3c749a0709061136p23197054oc7fa7f03cd4a9fa5@mail.gmail.com> <200709070015.l870Fmsg057826@www262.sakura.ne.jp> <8f3c749a0709070147n27679959wd47977c7799462d6@mail.gmail.com> Message-ID: <200709180340.l8I3e2E5060355@www262.sakura.ne.jp> 　熊猫です。 　今、 1.5.0 用の README を書いていますが、 クスノさんの作成したカラー表示機能についての メッセージはどのようにすればよろしいでしょうか？ editpolicy: Printing with colors is supported. Contributed by yocto. お名前は本名とハンドルのどちらを希望されますか？ メールアドレスは表示しますか？ ご希望の形をお知らせください。 よろしくお願いします。 From yocto1 ＠ gmail.com Wed Sep 19 00:05:22 2007 From: yocto1 ＠ gmail.com (yocto) Date: Wed, 19 Sep 2007 00:05:22 +0900 Subject: [Tomoyo-dev 570] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwlKCVHJSMlPyRLPydJVSQxGyhC?= In-Reply-To: <200709180340.l8I3e2E5060355@www262.sakura.ne.jp> References: <200707072336.FIB66431.PtSPEtPWNPNFGZU@I-love.SAKURA.ne.jp> <8f3c749a0707110720m637f1915w766ede05fd3330b7@mail.gmail.com> <200708102149.FCI21819.tZPtUNPNGPWSFPE@I-love.SAKURA.ne.jp> <8f3c749a0708110900p279e183dr9d93d2a345fac64d@mail.gmail.com> <200708120305.FEE57143.PEStFtUWNPGPZNP@I-love.SAKURA.ne.jp> <8f3c749a0708130758y4d4c74c6r4badf9ab81953365@mail.gmail.com> <8f3c749a0709061136p23197054oc7fa7f03cd4a9fa5@mail.gmail.com> <200709070015.l870Fmsg057826@www262.sakura.ne.jp> <8f3c749a0709070147n27679959wd47977c7799462d6@mail.gmail.com> <200709180340.l8I3e2E5060355@www262.sakura.ne.jp> Message-ID: <8f3c749a0709180805n57d2a85cqc4a93a674affb4f5@mail.gmail.com> クスノです。 では、本名とsourceforgeのメールアドレスでお願いします。 ＃毎回添削してもらってますが...(^^ゞ 07/09/18 に from-tomoyo-dev ＠ i-love.sakura.ne.jp さんは書きました: > 　熊猫です。 > > 今、 1.5.0 用の README を書いていますが、 > クスノさんの作成したカラー表示機能についての > メッセージはどのようにすればよろしいでしょうか？ > > editpolicy: > Printing with colors is supported. > Contributed by yocto. > > お名前は本名とハンドルのどちらを希望されますか？ > メールアドレスは表示しますか？ > > ご希望の形をお知らせください。 > よろしくお願いします。 > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev From from-tomoyo-dev ＠ i-love.sakura.ne.jp Fri Sep 21 15:43:57 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Fri, 21 Sep 2007 15:43:57 +0900 Subject: [Tomoyo-dev 571] =?iso-2022-jp?b?VE9NT1lPIExpbnV4IDEuNS4wIBskQiRyJWolaiE8JTkbKEI=?= =?iso-2022-jp?b?GyRCJDckXiQ3JD8hIxsoQg==?= Message-ID: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> 　熊猫です。 　社内決裁手続きが完了したので TOMOYO Linux 1.5.0 としてリリース物件にアップロードしました。 　開発会議やこのｍｌで議論したことの全部を実現できたわけではありませんが、 おかげさまでユーザにとって違和感を感じる部分はかなり除去できたかと思います。 ありがとうございました。 　これから、順次バイナリパッケージを作成していきたいと思いますので お時間に余裕のある方は手伝っていただけると嬉しいです。作業を始める前に http://tomoyo.sourceforge.jp/wiki/?HowToMakeKernelPackage の下の コンパイル状況欄にご記入ください。 （荒らし対策のためページが凍結されていますのでご注意ください。） 　ccs-tools パッケージに関して、 rpm 系のディストリビューションで共通に使える spec ファイルを含めました。 ccs-tools-1.5.0-20070920.tar.gz に含まれている ccs-tools.spec に対して rpmbuild -bb --target i386 ccs-tools.spec を実行することで ccs-tools-1.5.0-1.i386.rpm を作成できます。 これにより rpm 系のディストリビューションであれば カーネルもツールも rpm でインストールできるようになりました。 ユーザの使っているシェルの rc ファイルまでは知りようが無いので 環境変数 PATH の追加は手作業で行ってもらいますが、 1.5.0 では grub.conf に init=/.init を追加する必要も無くなったので インストールの障壁が減るはずです。 　残る課題は、 deb パッケージ向けの ccs-tools バイナリパッケージの作成と yum/apt レポジトリの構築ですね。 From yocto1 ＠ gmail.com Sat Sep 22 22:40:50 2007 From: yocto1 ＠ gmail.com (yocto) Date: Sat, 22 Sep 2007 22:40:50 +0900 Subject: [Tomoyo-dev 572] Re: =?iso-2022-jp?b?VE9NT1lPIExpbnV4IDEuNS4wIBskQiRyJWolaiE8GyhC?= =?iso-2022-jp?b?GyRCJTkkNyReJDckPyEjGyhC?= In-Reply-To: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> Message-ID: <8f3c749a0709220640r77bba74fjc1e9cafbafb8b439@mail.gmail.com> クスノです。 Sarge2.4、2.6とetchを置きました。 ＃grubにinitを追加する必要がないだけですごく楽な気がします。 07/09/21 に from-tomoyo-dev ＠ i-love.sakura.ne.jp さんは書きました: > 　熊猫です。 > > 社内決裁手続きが完了したので > TOMOYO Linux 1.5.0 としてリリース物件にアップロードしました。 > > 開発会議やこのｍｌで議論したことの全部を実現できたわけではありませんが、 > おかげさまでユーザにとって違和感を感じる部分はかなり除去できたかと思います。 > ありがとうございました。 > > これから、順次バイナリパッケージを作成していきたいと思いますので > お時間に余裕のある方は手伝っていただけると嬉しいです。作業を始める前に > http://tomoyo.sourceforge.jp/wiki/?HowToMakeKernelPackage の下の > コンパイル状況欄にご記入ください。 > （荒らし対策のためページが凍結されていますのでご注意ください。） > > ccs-tools パッケージに関して、 > rpm 系のディストリビューションで共通に使える spec ファイルを含めました。 > ccs-tools-1.5.0-20070920.tar.gz に含まれている ccs-tools.spec に対して > rpmbuild -bb --target i386 ccs-tools.spec を実行することで > ccs-tools-1.5.0-1.i386.rpm を作成できます。 > これにより rpm 系のディストリビューションであれば > カーネルもツールも rpm でインストールできるようになりました。 > ユーザの使っているシェルの rc ファイルまでは知りようが無いので > 環境変数 PATH の追加は手作業で行ってもらいますが、 > 1.5.0 では grub.conf に init=/.init を追加する必要も無くなったので > インストールの障壁が減るはずです。 > > 残る課題は、 deb パッケージ向けの ccs-tools バイナリパッケージの作成と > yum/apt レポジトリの構築ですね。 > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Sep 22 23:08:42 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 22 Sep 2007 23:08:42 +0900 Subject: [Tomoyo-dev 573] Re: =?iso-2022-jp?b?VE9NT1lPIExpbnV4IDEuNS4wIBskQiRyJWolaiE8GyhC?= =?iso-2022-jp?b?GyRCJTkkNyReJDckPyEjGyhC?= In-Reply-To: <8f3c749a0709220640r77bba74fjc1e9cafbafb8b439@mail.gmail.com> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> <8f3c749a0709220640r77bba74fjc1e9cafbafb8b439@mail.gmail.com> Message-ID: <200709222308.DIH41639.SPtNPZUPWGPFENt@I-love.SAKURA.ne.jp> 　熊猫です。 > Sarge2.4、2.6とetchを置きました。 ありがとうございます。 リリース物件への登録をお願いします。＞武田さん > ＃grubにinitを追加する必要がないだけですごく楽な気がします。 そうですね。 grub.conf がすっきりしましたね。 rpm や deb の post install スクリプトで grub.conf に追加させるのは面倒そうだなぁと思っていたところに、 ちょうど init= を使わないで済む方法が見つかったのはラッキーでした。 From haradats ＠ gmail.com Sat Sep 22 23:31:34 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Sat, 22 Sep 2007 23:31:34 +0900 Subject: [Tomoyo-dev 574] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwlKCVHJSMlPyRLPydJVSQxGyhC?= In-Reply-To: <8f3c749a0709061136p23197054oc7fa7f03cd4a9fa5@mail.gmail.com> References: <200707072336.FIB66431.PtSPEtPWNPNFGZU@I-love.SAKURA.ne.jp> <8f3c749a0707090718h7c69f4d9jaae4231f11672143@mail.gmail.com> <8f3c749a0707110720m637f1915w766ede05fd3330b7@mail.gmail.com> <200708102149.FCI21819.tZPtUNPNGPWSFPE@I-love.SAKURA.ne.jp> <8f3c749a0708110900p279e183dr9d93d2a345fac64d@mail.gmail.com> <200708120305.FEE57143.PEStFtUWNPGPZNP@I-love.SAKURA.ne.jp> <8f3c749a0708130758y4d4c74c6r4badf9ab81953365@mail.gmail.com> <8f3c749a0709061136p23197054oc7fa7f03cd4a9fa5@mail.gmail.com> Message-ID: <9d732d950709220731u5a5be0deqdb804af6951ae3e5@mail.gmail.com> 07/09/07 に yocto さんは書きました: > ・環境変数名 > EDITPOLICY_COLORS > > ・指定方法 > 環境変数名=指定箇所=前景色背景色:指定箇所=前景色背景色:〜 > EDITPOLICY_COLORS=DOMAIN_HEAD=02:DOMAIN_CURSOR=02:〜 > > ・指定箇所 > Domain Transition Editorのヘッダ部 DOMAIN_HEAD > Domain Transition Editorのカーソル行 DOMAIN_CURSOR > System Policy Editorのヘッダ部 SYSTEM_HEAD > System Policy Editorのカーソル行 SYSTEM_CURSOR > Exception Policy Editorのヘッダ部 EXCEPTION_HEAD > Exception Policy Editorのカーソル行 EXCEPTION_CURSOR > Domain Policy Editorのヘッダ部 ACL_HEAD > Domain Policy Editorのカーソル行 ACL_CURSOR > > > ・指定する色番号 > BLACK 0 > RED 1 > GREEN 2 > YELLOW 3 > BLUE 4 > MAGENTA 5 > CYAN 6 > WHITE 7 > > ・設定例（デフォルト設定） > EDITPOLICY_COLORS=DOMAIN_HEAD=02:DOMAIN_CURSOR=02:SYSTEM_HEAD=74:SYSTEM_CURSOR=74:EXCEPTION_HEAD=06:EXCEPTION_CURSOR=06:ACL_HEAD=03:ACL_CURSOR=03 > > ＃指定方法が間違っていると、デフォルト設定となります。 このメッセージを読んだ時には気にならなかったのですが、 editpolicyのためだけの指定であれば環境変数というよりは $HOME/.editpolicyrc のように設定ファイルでも良いかも しれませんね。また、EDITPOLICY_COLORSの 指定については、常に全項目を記述することとして （項目の並びを固定したうえで）、値のみをコロンで区切って 並べることができれば、各項目（属性）に名前まで 与えなくても良い気がしました。 EDITPOLICY_COLORS=02:02:74:74:06:06:03:03 とか、 OLICY_COLORS=:02:::::: 現仕様でも特に問題があるわけではないので、次回 仕様見直しの際の意見として投稿しました。 -- Toshiharu Harada haradats ＠ gmail.com From from-tomoyo-dev ＠ i-love.sakura.ne.jp Sun Sep 23 16:37:49 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Sun, 23 Sep 2007 16:37:49 +0900 Subject: [Tomoyo-dev 575] Re: =?iso-2022-jp?b?VE9NT1lPIExpbnV4IDEuNS4wIBskQiRyJWolaiE8GyhC?= =?iso-2022-jp?b?GyRCJTkkNyReJDckPyEjGyhC?= In-Reply-To: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> Message-ID: <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> 　熊猫です。 > 　残る課題は、 deb パッケージ向けの ccs-tools バイナリパッケージの作成と > yum/apt レポジトリの構築ですね。 　ccs-tools の deb パッケージ化についてですが、 alian というコマンドを使うと rpm から deb を作成できることが判りました。 手順は # apt-get install alien # rpmbuild -bb --target i386 ccs-tools.spec # alien -k /usr/src/rpm/RPMS/i386/ccs-tools-1.5.0-1.i386.rpm だけです。 Debian Sarge/Etch と Ubuntu 6.10/7.04 で使えることを確認しましたので、 この方法を使いたいと思います。 各ディストリビューションで共通に使えるようにするために ccs-tools.spec の中には ディストリビューション名を入れないようにしているため、 どのディストリビューションで作成した場合も ccs-tools-1.5.0-1.i386.rpm という ファイル名になってしまいます。 リリース物件が置かれるディレクトリ（http://osdn.dl.sourceforge.jp/tomoyo/?????/）には サブディレクトリを作成できないので、ファイル名で区別できるようように ccs-tools-1.5.0-1.ディストリビューション名.i386.rpm ccs-tools_1.5.0-1_ディストリビューション名_i386.deb という名前にリネームして登録しようと思います。 From henrich ＠ debian.or.jp Wed Sep 26 22:59:21 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Wed, 26 Sep 2007 22:59:21 +0900 Subject: [Tomoyo-dev 576] =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQiAoUmU6IFRPTU9ZTyBMaW51eCAx?= =?iso-2022-jp?b?LjUuMCAbJEIkciVqJWohPCU5JDckXiQ3JD8hIxsoQik=?= In-Reply-To: <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> Message-ID: <20070926225921.b32b6dcf.henrich@debian.or.jp> 　はじめまして、やまねといいます。 　Debian パッケージ化に興味を持っています。 On Sun, 23 Sep 2007 16:37:49 +0900 from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) wrote: > 　ccs-tools の deb パッケージ化についてですが、 > alian というコマンドを使うと rpm から deb を作成できることが判りました。 　alien はソースが無いときの回避策ぐらいであって、実際にソースが 　あるならきちんとパッケージ化を行った方がよいと思います。 　あと気になったのですが、unstable 用パッケージ／ソースパッケージ 　は用意されていませんか？ないなら作ってみようと思ったので。 <余談> 　Debian の場合は 　　開発版　　＝ unstable 　　↓（通常10日間すると自動でコピー。フリーズされるまでそのまま） 　　テスト版　＝ testing　（次期リリース版） 　　↓（リリース作業） 　　安定版　　＝ stable　 （リリース版） 　という開発の流れが有るので、 unstable なカーネルパッケージに対して 　作業が進んでいると取り入れやすいです。安定版は基本的に開発版からの 　backport を作業を行って、backrposts.org （半公式の backport 用プロ 　ジェクト）に持っていく、というのが最近の流れになっています。 　開発版にパッケージを持っていくには、公式開発者の誰かにスポンサーに 　なってもらって sponsored upload をしてもらえば、特にライセンス的な 　問題がなければ１ヶ月もすれば Official Repository に入れることが可能 　です（実体験として）。 　 　 -- Regards, Hideki Yamane henrich @ debian.or.jp From haradats ＠ gmail.com Wed Sep 26 23:24:07 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Wed, 26 Sep 2007 23:24:07 +0900 Subject: [Tomoyo-dev 577] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQiAoUmU6IFRPTU9ZTyBMaW51?= =?iso-2022-jp?b?eCAxLjUuMCAbJEIkciVqJWohPCU5JDckXiQ3JD8hIxsoQik=?= In-Reply-To: <20070926225921.b32b6dcf.henrich@debian.or.jp> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> <20070926225921.b32b6dcf.henrich@debian.or.jp> Message-ID: <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> やまね様、 はじめまして。 07/09/26 に Hideki Yamane さんは書きました: > > はじめまして、やまねといいます。 > Debian パッケージ化に興味を持っています。 > > On Sun, 23 Sep 2007 16:37:49 +0900 > from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) wrote: > > ccs-tools の deb パッケージ化についてですが、 > > alian というコマンドを使うと rpm から deb を作成できることが判りました。 > > alien はソースが無いときの回避策ぐらいであって、実際にソースが > あるならきちんとパッケージ化を行った方がよいと思います。 そうですね。 > あと気になったのですが、unstable 用パッケージ／ソースパッケージ > は用意されていませんか？ないなら作ってみようと思ったので。 TOMOYOプロジェクトはフルタイムの開発メンバーは現状2名で、 かつLKLM提案のための作業を行っています。これまで メイン(stable相当)以外のリリースを行うことは考えていませんでした。 幸い、開発を手伝っていただける方々が増えてきたので、 1.5以降のリリースのあり方ということで見直した方が 良いですね。 > <余談> > Debian の場合は > > 開発版　　＝ unstable > ↓（通常10日間すると自動でコピー。フリーズされるまでそのまま） > テスト版　＝ testing　（次期リリース版） > ↓（リリース作業） > 安定版　　＝ stable　 （リリース版） > > という開発の流れが有るので、 unstable なカーネルパッケージに対して > 作業が進んでいると取り入れやすいです。安定版は基本的に開発版からの > backport を作業を行って、backrposts.org （半公式の backport 用プロ > ジェクト）に持っていく、というのが最近の流れになっています。 > > 開発版にパッケージを持っていくには、公式開発者の誰かにスポンサーに > なってもらって sponsored upload をしてもらえば、特にライセンス的な > 問題がなければ１ヶ月もすれば Official Repository に入れることが可能 > です（実体験として）。 Debianを含めディストリビューションに入れたいのはやまやまですが、 手順とコンタクト先がわかっていません。このような情報は 大変参考になります。 -- Toshiharu Harada haradats ＠ gmail.com From henrich ＠ debian.or.jp Thu Sep 27 00:24:15 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Thu, 27 Sep 2007 00:24:15 +0900 Subject: [Tomoyo-dev 578] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> <20070926225921.b32b6dcf.henrich@debian.or.jp> <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> Message-ID: <20070927002415.50a2b04a.henrich@debian.or.jp> 　やまねです。 On Wed, 26 Sep 2007 23:24:07 +0900 "Toshiharu Harada" wrote: > はじめまして。 　どもです。 > > alien はソースが無いときの回避策ぐらいであって、実際にソースが > > あるならきちんとパッケージ化を行った方がよいと思います。 　手元で ccstools ちょっとだけやってみました。 　気になった点 　・ccs-init、 tomoyo-init、 init_policy.sh、tomoyo_init_policy.sh 　　が #! /bin/bash になっている。bash 依存よくないっす 　・ccstools の copyright と作者の連絡先はどこになるんでしょう? 　・GPL は 2 のみでしょうか。それとも 2 or later（どこかに書いてあるかも） 　・Makefile が結構ベタがきかなーと。適宜改行が入ると見やすいですね。 　・man は用意される？ 　あ、あと 　・http://tomoyo.sourceforge.jp/ja/1.5.x/1st-step/etch/ 　　でなぜか手順の途中で rpm --install になってます。dpkg -i ですね > TOMOYOプロジェクトはフルタイムの開発メンバーは現状2名で、 > かつLKLM提案のための作業を行っています。これまで > メイン(stable相当)以外のリリースを行うことは考えていませんでした。 　なるほど。 　Distribution の場合、パッケージごとの stable なものが distro の 　unstable に入りますから、ちょっとこの点の思考の整理が必要かもし 　れません。 　＃distro 自体が実験要素の強いものを自身で開発するとき以外は、 　　パッケージ自体は stable リリースされたものが入ることが多いと 　　思います。 > Debianを含めディストリビューションに入れたいのはやまやまですが、 > 手順とコンタクト先がわかっていません。このような情報は > 大変参考になります。 　参考になったのであれば幸いです。開発者のリファレンスとか訳とか 　まとめとかしようとしてるんですが、なかなか進みません。 　＃まぁ私ですらパッケージ入れられたぐらいなので、ちょっと分かれば 　　結構するっと入るもんです、はい。 :-) From yocto1 ＠ gmail.com Thu Sep 27 00:54:48 2007 From: yocto1 ＠ gmail.com (yocto) Date: Thu, 27 Sep 2007 00:54:48 +0900 Subject: [Tomoyo-dev 579] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <20070927002415.50a2b04a.henrich@debian.or.jp> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> <20070926225921.b32b6dcf.henrich@debian.or.jp> <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> <20070927002415.50a2b04a.henrich@debian.or.jp> Message-ID: <8f3c749a0709260854o55861a0bq7fb3278ed9ae5d19@mail.gmail.com> 始めまして、クスノと申します。 現状のカーネルパッケージも、debになっているというだけでDebianの作法にはまったく なっていないので、ぜひ やまねさんに教えていただきたいですm(__)m 07/09/27 に Hideki Yamane さんは書きました: > > やまねです。 > > On Wed, 26 Sep 2007 23:24:07 +0900 > "Toshiharu Harada" wrote: > > はじめまして。 > > どもです。 > > > > > alien はソースが無いときの回避策ぐらいであって、実際にソースが > > > あるならきちんとパッケージ化を行った方がよいと思います。 > > 手元で ccstools ちょっとだけやってみました。 > 気になった点 > ・ccs-init、 tomoyo-init、 init_policy.sh、tomoyo_init_policy.sh > が #! /bin/bash になっている。bash 依存よくないっす > ・ccstools の copyright と作者の連絡先はどこになるんでしょう? > ・GPL は 2 のみでしょうか。それとも 2 or later（どこかに書いてあるかも） > ・Makefile が結構ベタがきかなーと。適宜改行が入ると見やすいですね。 > ・man は用意される？ > > あ、あと > ・http://tomoyo.sourceforge.jp/ja/1.5.x/1st-step/etch/ > でなぜか手順の途中で rpm --install になってます。dpkg -i ですね > > > > TOMOYOプロジェクトはフルタイムの開発メンバーは現状2名で、 > > かつLKLM提案のための作業を行っています。これまで > > メイン(stable相当)以外のリリースを行うことは考えていませんでした。 > > なるほど。 > > Distribution の場合、パッケージごとの stable なものが distro の > unstable に入りますから、ちょっとこの点の思考の整理が必要かもし > れません。 > > ＃distro 自体が実験要素の強いものを自身で開発するとき以外は、 > パッケージ自体は stable リリースされたものが入ることが多いと > 思います。 > > > > Debianを含めディストリビューションに入れたいのはやまやまですが、 > > 手順とコンタクト先がわかっていません。このような情報は > > 大変参考になります。 > > 参考になったのであれば幸いです。開発者のリファレンスとか訳とか > まとめとかしようとしてるんですが、なかなか進みません。 > > ＃まぁ私ですらパッケージ入れられたぐらいなので、ちょっと分かれば > 結構するっと入るもんです、はい。 :-) > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > From yocto1 ＠ gmail.com Thu Sep 27 01:02:33 2007 From: yocto1 ＠ gmail.com (yocto) Date: Thu, 27 Sep 2007 01:02:33 +0900 Subject: [Tomoyo-dev 580] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwlKCVHJSMlPyRLPydJVSQxGyhC?= In-Reply-To: <9d732d950709220731u5a5be0deqdb804af6951ae3e5@mail.gmail.com> References: <200707072336.FIB66431.PtSPEtPWNPNFGZU@I-love.SAKURA.ne.jp> <8f3c749a0707090718h7c69f4d9jaae4231f11672143@mail.gmail.com> <8f3c749a0707110720m637f1915w766ede05fd3330b7@mail.gmail.com> <200708102149.FCI21819.tZPtUNPNGPWSFPE@I-love.SAKURA.ne.jp> <8f3c749a0708110900p279e183dr9d93d2a345fac64d@mail.gmail.com> <200708120305.FEE57143.PEStFtUWNPGPZNP@I-love.SAKURA.ne.jp> <8f3c749a0708130758y4d4c74c6r4badf9ab81953365@mail.gmail.com> <8f3c749a0709061136p23197054oc7fa7f03cd4a9fa5@mail.gmail.com> <9d732d950709220731u5a5be0deqdb804af6951ae3e5@mail.gmail.com> Message-ID: <8f3c749a0709260902r2beed6c8n3cd91270899b0785@mail.gmail.com> クスノです。 設定ファイルの件は、最初に熊猫さんが言っていたのですが、私が環境変数のほうが 楽ですと言ったのでした。 で、指定方法は仰るとおり長くてやだなとは思ったのですが、とりあえずべたに作ってみました。 07/09/22 に Toshiharu Harada さんは書きました: > 07/09/07 に yocto さんは書きました: > > ・環境変数名 > > EDITPOLICY_COLORS > > > > ・指定方法 > > 環境変数名=指定箇所=前景色背景色:指定箇所=前景色背景色:〜 > > EDITPOLICY_COLORS=DOMAIN_HEAD=02:DOMAIN_CURSOR=02:〜 > > > > ・指定箇所 > > Domain Transition Editorのヘッダ部 DOMAIN_HEAD > > Domain Transition Editorのカーソル行 DOMAIN_CURSOR > > System Policy Editorのヘッダ部 SYSTEM_HEAD > > System Policy Editorのカーソル行 SYSTEM_CURSOR > > Exception Policy Editorのヘッダ部 EXCEPTION_HEAD > > Exception Policy Editorのカーソル行 EXCEPTION_CURSOR > > Domain Policy Editorのヘッダ部 ACL_HEAD > > Domain Policy Editorのカーソル行 ACL_CURSOR > > > > > > ・指定する色番号 > > BLACK 0 > > RED 1 > > GREEN 2 > > YELLOW 3 > > BLUE 4 > > MAGENTA 5 > > CYAN 6 > > WHITE 7 > > > > ・設定例（デフォルト設定） > > EDITPOLICY_COLORS=DOMAIN_HEAD=02:DOMAIN_CURSOR=02:SYSTEM_HEAD=74:SYSTEM_CURSOR=74:EXCEPTION_HEAD=06:EXCEPTION_CURSOR=06:ACL_HEAD=03:ACL_CURSOR=03 > > > > ＃指定方法が間違っていると、デフォルト設定となります。 > > このメッセージを読んだ時には気にならなかったのですが、 > editpolicyのためだけの指定であれば環境変数というよりは > $HOME/.editpolicyrc のように設定ファイルでも良いかも > しれませんね。また、EDITPOLICY_COLORSの > 指定については、常に全項目を記述することとして > （項目の並びを固定したうえで）、値のみをコロンで区切って > 並べることができれば、各項目（属性）に名前まで > 与えなくても良い気がしました。 > > EDITPOLICY_COLORS=02:02:74:74:06:06:03:03 とか、 > OLICY_COLORS=:02:::::: > > 現仕様でも特に問題があるわけではないので、次回 > 仕様見直しの際の意見として投稿しました。 > > -- > Toshiharu Harada > haradats ＠ gmail.com > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Sep 27 01:11:01 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 27 Sep 2007 01:11:01 +0900 Subject: [Tomoyo-dev 581] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <20070927002415.50a2b04a.henrich@debian.or.jp> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> <20070926225921.b32b6dcf.henrich@debian.or.jp> <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> <20070927002415.50a2b04a.henrich@debian.or.jp> Message-ID: <200709261611.l8QGB18d036994@www262.sakura.ne.jp> 　こんばんは、やまねさん。 > > > alien はソースが無いときの回避策ぐらいであって、実際にソースが > > > あるならきちんとパッケージ化を行った方がよいと思います。 deb パッケージ作成のためのディレクトリや設定ファイルを作成してコマンドを叩くのが面倒なので、 全ディストリビューションで共通に使える手順として alien を使っています。 ディストリビューションのパッケージ作成流儀に詳しい方がおられれば その方法で作成していただきたいと思います。 （例えば Nature's Linux 1.5.1 の場合は Matthew さんが Nature's Linux の流儀で作成されています。） > 　　が #! /bin/bash になっている。bash 依存よくないっす 現在サポートしているディストリビューションの中に /bin/sh だと動かないものがあったので /bin/bash を使っています。 （カーネルへのパッチ以外は、サポートしている全てのディストリビューションで 同一のソースコード／同一の手順が使えるように設計しています。） C で作成したバイナリプログラムで置き換えてしまう方法もありますが、 スクリプトのままディストリビューション毎にソースを管理するのと どちらが宜しいでしょうね？ > 　・http://tomoyo.sourceforge.jp/ja/1.5.x/1st-step/etch/ > 　　でなぜか手順の途中で rpm --install になってます。dpkg -i ですね ありがとうございます。 CentOS の手順書からコピーして修正するのを忘れていました。 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Sep 27 01:16:06 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 27 Sep 2007 01:16:06 +0900 Subject: [Tomoyo-dev 582] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwlKCVHJSMlPyRLPydJVSQxGyhC?= In-Reply-To: <8f3c749a0709260902r2beed6c8n3cd91270899b0785@mail.gmail.com> References: <200707072336.FIB66431.PtSPEtPWNPNFGZU@I-love.SAKURA.ne.jp> <8f3c749a0707090718h7c69f4d9jaae4231f11672143@mail.gmail.com> <8f3c749a0707110720m637f1915w766ede05fd3330b7@mail.gmail.com> <200708102149.FCI21819.tZPtUNPNGPWSFPE@I-love.SAKURA.ne.jp> <8f3c749a0708110900p279e183dr9d93d2a345fac64d@mail.gmail.com> <200708120305.FEE57143.PEStFtUWNPGPZNP@I-love.SAKURA.ne.jp> <8f3c749a0708130758y4d4c74c6r4badf9ab81953365@mail.gmail.com> <8f3c749a0709061136p23197054oc7fa7f03cd4a9fa5@mail.gmail.com> <9d732d950709220731u5a5be0deqdb804af6951ae3e5@mail.gmail.com> <8f3c749a0709260902r2beed6c8n3cd91270899b0785@mail.gmail.com> Message-ID: <200709261616.l8QGG6JJ038344@www262.sakura.ne.jp> 　熊猫です。 > 設定ファイルの件は、最初に熊猫さんが言っていたのですが、私が環境変数のほうが > 楽ですと言ったのでした。 > で、指定方法は仰るとおり長くてやだなとは思ったのですが、とりあえずべたに作ってみました。 /bin/ls の場合は設定ファイルではなく環境変数 LS_COLORS を使っているので editpolicy も環境変数のままで構わないと思います。 項目名を短い名前にするのと解りやすい名前にするかで悩みそうです。 From haradats ＠ gmail.com Thu Sep 27 07:00:56 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Thu, 27 Sep 2007 07:00:56 +0900 Subject: [Tomoyo-dev 583] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwlKCVHJSMlPyRLPydJVSQxGyhC?= In-Reply-To: <200709261616.l8QGG6JJ038344@www262.sakura.ne.jp> References: <200707072336.FIB66431.PtSPEtPWNPNFGZU@I-love.SAKURA.ne.jp> <8f3c749a0707110720m637f1915w766ede05fd3330b7@mail.gmail.com> <200708102149.FCI21819.tZPtUNPNGPWSFPE@I-love.SAKURA.ne.jp> <8f3c749a0708110900p279e183dr9d93d2a345fac64d@mail.gmail.com> <200708120305.FEE57143.PEStFtUWNPGPZNP@I-love.SAKURA.ne.jp> <8f3c749a0708130758y4d4c74c6r4badf9ab81953365@mail.gmail.com> <8f3c749a0709061136p23197054oc7fa7f03cd4a9fa5@mail.gmail.com> <9d732d950709220731u5a5be0deqdb804af6951ae3e5@mail.gmail.com> <8f3c749a0709260902r2beed6c8n3cd91270899b0785@mail.gmail.com> <200709261616.l8QGG6JJ038344@www262.sakura.ne.jp> Message-ID: <9d732d950709261500m5ff7d856u668b565a434fa212@mail.gmail.com> 07/09/27 に from-tomoyo-dev ＠ i-love.sakura.ne.jp さんは書きました: > 　熊猫です。 > > > 設定ファイルの件は、最初に熊猫さんが言っていたのですが、私が環境変数のほうが > > 楽ですと言ったのでした。 > > で、指定方法は仰るとおり長くてやだなとは思ったのですが、とりあえずべたに作ってみました。 > /bin/ls の場合は設定ファイルではなく環境変数 LS_COLORS を使っているので > editpolicy も環境変数のままで構わないと思います。 「lsでも使っているから」とのことですが、オプション指定に環境変数を 使うこと自体がおかしいと言っているわけではないのです。 『editpolicyのためだけの指定であれば環境変数というよりは $HOME/.editpolicyrc のように設定ファイルでも良いかもしれない』と 思いました、ということです。 > 項目名を短い名前にするのと解りやすい名前にするかで悩みそうです。 これは現状の仕様のままで、各色の属性名称を短い名前にすると いうことですか？ また繰り返しになりますが、環境変数の使用を継続する場合も わざわざ色毎の名前をつける必要はないと思います。editpolicy用の 環境変数であることがすぐわかる名前が（ひとつ）あって、 その並びや説明はman editpolicyで見られたらそれで良いと思います。 いずれにしても、現仕様でも特に問題があるわけではないので、次回 仕様見直しの際の意見です。 -- Toshiharu Harada haradats ＠ gmail.com From henrich ＠ debian.or.jp Fri Sep 28 01:03:43 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Fri, 28 Sep 2007 01:03:43 +0900 Subject: [Tomoyo-dev 584] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <200709261611.l8QGB18d036994@www262.sakura.ne.jp> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> <20070926225921.b32b6dcf.henrich@debian.or.jp> <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> Message-ID: <20070928010343.62321f5f.henrich@debian.or.jp> 　やまね％駆け出しぱっけーじめんてな、です。 On Thu, 27 Sep 2007 01:11:01 +0900 from-tomoyo-dev ＠ i-love.sakura.ne.jp wrote: > deb パッケージ作成のためのディレクトリや設定ファイルを作成してコマンドを叩くのが面倒なので、 > 全ディストリビューションで共通に使える手順として alien を使っています。 > ディストリビューションのパッケージ作成流儀に詳しい方がおられれば > その方法で作成していただきたいと思います。 　一旦ソースパッケージを作ってしまえば、ものすごく元のソースが変わって 　なければコマンド2つでアップデート→ビルドできますので、最初の部分では 　面倒ですが、ソースパッケージ作ってしまおうと思います。 <余談その2> 　一旦 Debian の main ディストリビューションに入れば、暫くすると 　Ubuntu の Universe ディストリビューションにコピーされてたりし 　ます。どのタイミングでやってるかは謎なんですが。Ubuntu の場合、 　よっぽど腰据えて自力でやろう、と思うパッケージ以外はうまいこと 　「サポートしないけどね」の Universe に入れて対応という形になる 　ので、個人的には Debian の main に入れてしまえば旨いこと他にも 　対応したことになるかと思います。 > > 　　が #! /bin/bash になっている。bash 依存よくないっす > 現在サポートしているディストリビューションの中に > /bin/sh だと動かないものがあったので /bin/bash を使っています。 　それは具体的にはどのdistroでどんな症状だったのでしょう？ 　＃興味から聞いています。 > C で作成したバイナリプログラムで置き換えてしまう方法もありますが、 > スクリプトのままディストリビューション毎にソースを管理するのと > どちらが宜しいでしょうね？ 　まぁ、パッケージ側のパッチで書き換えもありなので、まだ考え 　なくてもいいと思います。 　あとパッケージにする際には色々と細かなところが気になります。 > > 　・ccstools の copyright と作者の連絡先はどこになるんでしょう? 　copyright は (c) 2005-2007 NTT DATA Corporation でしょうか？ 　作者連絡先は…どうするのが良いでしょうか？ > > 　・GPL は 2 のみでしょうか。それとも 2 or later（どこかに書いてあるかも） 　ccstool 内には記載が無いような…ライセンス文章はどこでしょう？ 　GPL だとは色々なところに書いてあるのですが、ライセンス文が無いと 　本当にそうなのか不安になりました ;-) 　大抵の場合、 　・AUTHORS　に作者らの名前と連絡先 　・COPYING　にライセンスについて　　　が記載されている場合が多いです。 > > 　・Makefile が結構ベタがきかなーと。適宜改行が入ると見やすいですね。 > > 　・man は用意される？ 　使い方はこれをよめ、というドキュメントはどれになりますか？ From hitoht ＠ gmail.com Fri Sep 28 08:43:28 2007 From: hitoht ＠ gmail.com (hito) Date: Fri, 28 Sep 2007 08:43:28 +0900 Subject: [Tomoyo-dev 585] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <20070928010343.62321f5f.henrich@debian.or.jp> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> <20070926225921.b32b6dcf.henrich@debian.or.jp> <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> Message-ID: <9292c1390709271643n6f5e9fackc99c6d33eed9bfbf@mail.gmail.com> > <余談その2> > 　一旦 Debian の main ディストリビューションに入れば、暫くすると > 　Ubuntu の Universe ディストリビューションにコピーされてたりし > 　ます。どのタイミングでやってるかは謎なんですが。Ubuntu の場合、 > 　よっぽど腰据えて自力でやろう、と思うパッケージ以外はうまいこと > 　「サポートしないけどね」の Universe に入れて対応という形になる > 　ので、個人的には Debian の main に入れてしまえば旨いこと他にも > 　対応したことになるかと思います。 > 余談にコメントするのも大変アレな感じですが、ユーザランドにある パッケージと異なり、kernel packageは非互換（Ubuntu的な追加の デザインがあったり）で、DebianのMainに入れてもUbuntuの Universeには入りません……。 MOTU Teamの人がコンバートしてくれれば入りそうな気もしますが、無名に 近いTOMOYOがフォローされる可能性は高くなさそうです。 # ので、これはこれで作業中です……。 From haradats ＠ gmail.com Fri Sep 28 10:54:05 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Fri, 28 Sep 2007 10:54:05 +0900 Subject: [Tomoyo-dev 586] =?iso-2022-jp?b?Y2NzdG9vbHMbJEIkTj0kQDVEczBGGyhC?= Message-ID: <9d732d950709271854x3e2dbbe5o52e7a6b91b2b3c97@mail.gmail.com> 1.5のMakefileから抜粋： all: tomoyo syaoran cerberus tomoyo: ccs-auditd ccs-queryd ccstree checkpolicy editpolicy editpolicy_offline findtemp ld-watch loadpolicy pathmatch patternize savepolicy setlevel setprofile sortpolicy realpath syaoran: makesyaoranconf cerberus: candy chaplet checktoken falsh gettoken groovy honey mailauth proxy timeauth これについて、以下の点が気になります。 ・syaoran, cerberusをallに含める必要はないのでは？ ・cerberusの下は、位置づけ的にはexampleであるが 　それがわからない。 ・mailatuhのコンパイルにlibssl-devが必要（ないと 　makeが失敗する→本来必須でないことがわからず 　ここでlibssl-devを追加させている可能性がある） ということで提案します。 ・allのtargetはtomoyoのみにする。 ・ccstools\examplesのディレクトリを作成し、 　sampleプログラムをmvする。（以前もそのような話題が 　出ていた気がします） -- Toshiharu Harada haradats ＠ gmail.com From haradats ＠ gmail.com Fri Sep 28 11:00:16 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Fri, 28 Sep 2007 11:00:16 +0900 Subject: [Tomoyo-dev 587] =?iso-2022-jp?b?c3BlYywgcGF0Y2gbJEIkTkNWJC0+bCRLJEQkJCRGGyhC?= Message-ID: <9d732d950709271900i69721613oe2a23c7b6ec0455b@mail.gmail.com> 一部ユーザから、specやpatchをフラットに置くのは 良くないという意見が出ています。 参考： http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/?v=linux-2.6.22.7-tomoyo-1.5 そこで、ディレクトリを作成し、まとめることを提案します。 以下たたき台として案を書きます。 ccspatch-* -> ccs-patches/ config.ccs -> ccs-specs/ spec* -> ccs-specs/ -- Toshiharu Harada haradats ＠ gmail.com From from-tomoyo-dev ＠ i-love.sakura.ne.jp Fri Sep 28 11:01:52 2007 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Fri, 28 Sep 2007 11:01:52 +0900 Subject: [Tomoyo-dev 588] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <20070928010343.62321f5f.henrich@debian.or.jp> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> <20070926225921.b32b6dcf.henrich@debian.or.jp> <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> Message-ID: <200709280201.l8S21qia075749@www262.sakura.ne.jp> > > > 　　が #! /bin/bash になっている。bash 依存よくないっす > > 現在サポートしているディストリビューションの中に > > /bin/sh だと動かないものがあったので /bin/bash を使っています。 > > 　それは具体的にはどのdistroでどんな症状だったのでしょう？ > 　＃興味から聞いています。 Ubuntu 6.10 です。エラーメッセージは忘れました。 /bin/sh は大抵 /bin/bash へのシンボリックリンクになっていますが、 たまに /bin/dash へのシンボリックリンクになっている環境があります。 /bin/sh の仕様だと思って書いたものが実は /bin/bash でないと使えない というケースに Ubuntu で遭遇したので、 /bin/sh ではなく /bin/bash と 明示するようにしました。 今検索したら↓のようなページが見つかりました。 https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463 > > > 　・ccstools の copyright と作者の連絡先はどこになるんでしょう? > > 　copyright は (c) 2005-2007 NTT DATA Corporation でしょうか？ > 　作者連絡先は…どうするのが良いでしょうか？ 連絡先がメールアドレスではなくＵＲＬというのは不可ですか？ > > > 　・GPL は 2 のみでしょうか。それとも 2 or later（どこかに書いてあるかも） カーネルソースと同じ扱いだと思います。 > 　使い方はこれをよめ、というドキュメントはどれになりますか？ http://tomoyo.sourceforge.jp/en/1.5.x/tools-doc.html です。 From haradats ＠ gmail.com Fri Sep 28 17:34:31 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Fri, 28 Sep 2007 17:34:31 +0900 Subject: [Tomoyo-dev 589] TOMOYO on LFS Message-ID: <9d732d950709280134p2c82c042h1c89b2a1f59e0030@mail.gmail.com> 最近、SourceForge.jpのOpen Discussionのフォーラムに 英語での書き込みがありました。 内容は、"LFS (Linux From Scratch)"でTOMOYO Linuxを使いたい、 ということだったのですが、さきほど無事動作したという 報告がありました。 LFSについては、 http://www.linuxfromscratch.org/ フォーラムは http://sourceforge.jp/forum/forum.php?forum_id=11352 （スレッドまでURLに含めるとスパムに攻撃されるので トップレベルです。LFSで探してください） 親切にも手順をまとめてくれているので、近いうちに プロジェクトのwiki/webに追加しようと思っています。 今後、海外の方も利用して欲しいので、tomoyo-usersと tomoyo-devについて、日本語以外に英語を追加し、 デフォルトの言語を英語に変更しました。各ユーザは 表示する言語を選択できるので特に支障ないはずですが、 何かお気づきの点があればお知らせ下さい。 -- Toshiharu Harada haradats ＠ gmail.com From nez ＠ samba.gr.jp Fri Sep 28 11:32:44 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Fri, 28 Sep 2007 11:32:44 +0900 (JST) Subject: [Tomoyo-dev 590] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <200709280201.l8S21qia075749@www262.sakura.ne.jp> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp><200709230737.l8N7bnAK030913@www262.sakura.ne.jp><20070926225921.b32b6dcf.henrich@debian.or.jp><9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com><20070927002415.50a2b04a.henrich@debian.or.jp><200709261611.l8QGB18d036994@www262.sakura.ne.jp><20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> Message-ID: <6331.163.135.10.35.1190946764.squirrel@webmail.knlab.com> 根津です。 On 2007年 9月 28日 (金) 11:01, from-tomoyo-dev ＠ i-love.sakura.ne.jp wrote: >> > > 　　が #! /bin/bash になっている。bash 依存よくないっす >> > 現在サポートしているディストリビューションの中に >> > /bin/sh だと動かないものがあったので /bin/bash を使っています。 >> >> 　それは具体的にはどのdistroでどんな症状だったのでしょう？ >> 　＃興味から聞いています。 > > Ubuntu 6.10 です。エラーメッセージは忘れました。 > /bin/sh は大抵 /bin/bash へのシンボリックリンクになっていますが、 > たまに /bin/dash へのシンボリックリンクになっている環境があります。 > /bin/sh の仕様だと思って書いたものが実は /bin/bash でないと使えない > というケースに Ubuntu で遭遇したので、 /bin/sh ではなく /bin/bash と > 明示するようにしました。 それは、シェルスクリプトをshのスペックで記述するように修正する方が いいんじゃないですか？具体的に、bashのどの機能が必須だからbashを 明示指定したかによるとは思いますが・・・。 参考までにbashの何の機能を使用されたのでしょうか？ -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From henrich ＠ debian.or.jp Sat Sep 29 14:14:55 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sat, 29 Sep 2007 14:14:55 +0900 Subject: [Tomoyo-dev 591] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <200709280201.l8S21qia075749@www262.sakura.ne.jp> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> <20070926225921.b32b6dcf.henrich@debian.or.jp> <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> Message-ID: <20070929141455.4d6c6405.henrich@debian.or.jp> 　やまねです。 　どうしてもパッケージャーとしての立場からの物言いが多くなりますが 　ご容赦を。 On Fri, 28 Sep 2007 11:01:52 +0900 from-tomoyo-dev ＠ i-love.sakura.ne.jp wrote: > Ubuntu 6.10 です。エラーメッセージは忘れました。 > /bin/sh は大抵 /bin/bash へのシンボリックリンクになっていますが、 > たまに /bin/dash へのシンボリックリンクになっている環境があります。 　なるほど。そうですね。 > /bin/sh の仕様だと思って書いたものが実は /bin/bash でないと使えない > というケースに Ubuntu で遭遇したので、 /bin/sh ではなく /bin/bash と > 明示するようにしました。 　Debian Policy 上は、 　・sh 準拠（これが望ましい） 　・ダメなら bash と明示 　でした。なので通ることは通りますね。 > > > > 　・ccstools の copyright と作者の連絡先はどこになるんでしょう? > > > > 　copyright は (c) 2005-2007 NTT DATA Corporation でしょうか？ > > 　作者連絡先は…どうするのが良いでしょうか？ > 連絡先がメールアドレスではなくＵＲＬというのは不可ですか？ 　利用者が連絡が取れればOKですが、できる限りメールアドレスの方が 　ありがたいと思います。 　＃名刺に住所だけ書いてあって、連絡取ろうとすると苦労する、みたいな。 　　会社なので、色々手続きが面倒なことがある、などということであるとも 　　思いますので無理強いというわけではありません。 > > > > 　・GPL は 2 のみでしょうか。それとも 2 or later（どこかに書いてあるかも） > カーネルソースと同じ扱いだと思います。 　明示的にライセンスを記載した文章が無いと利用者側は面倒なことに 　なりますので、同梱してください。（これは先の連絡先より重要です） 　 > > 　使い方はこれをよめ、というドキュメントはどれになりますか？ > http://tomoyo.sourceforge.jp/en/1.5.x/tools-doc.html です。 　ありがとうございます。了解しました。 　このページは xml/sgml などから生成でしょうか？もしそうなら man に 　流用したいと思っています。 From henrich ＠ debian.or.jp Sat Sep 29 14:16:05 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sat, 29 Sep 2007 14:16:05 +0900 Subject: [Tomoyo-dev 592] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <6331.163.135.10.35.1190946764.squirrel@webmail.knlab.com> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> <20070926225921.b32b6dcf.henrich@debian.or.jp> <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> <6331.163.135.10.35.1190946764.squirrel@webmail.knlab.com> Message-ID: <20070929141605.8168f3f2.henrich@debian.or.jp> 　やまねです。 On Fri, 28 Sep 2007 11:32:44 +0900 (JST) "Kensuke Nezu" wrote: > 根津です。 　 　ども。 > それは、シェルスクリプトをshのスペックで記述するように修正する方が > いいんじゃないですか？具体的に、bashのどの機能が必須だからbashを > 明示指定したかによるとは思いますが・・・。 　その通りですね。 From henrich ＠ debian.or.jp Sat Sep 29 15:16:55 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sat, 29 Sep 2007 15:16:55 +0900 Subject: [Tomoyo-dev 593] =?iso-2022-jp?b?Y2NzdG9vbHMgTWFrZWZpbGUgGyRCIUobKEJSZTogYWxpZW4g?= =?iso-2022-jp?b?GyRCJFskKxsoQg==?= In-Reply-To: <20070927002415.50a2b04a.henrich@debian.or.jp> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> <20070926225921.b32b6dcf.henrich@debian.or.jp> <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> <20070927002415.50a2b04a.henrich@debian.or.jp> Message-ID: <20070929151655.c4b49037.henrich@debian.or.jp> 　やまねです。 On Thu, 27 Sep 2007 00:24:15 +0900 Hideki Yamane wrote: > 　・Makefile が結構ベタがきかなーと。適宜改行が入ると見やすいですね。 　いうだけでは何なので、手元ではこんな風にしてみました。 　＃gcc -O2 ではなく -O3 なのは何か理由があります？ -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: Makefile.dpatch 型: application/octet-stream サイズ: 4692 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/attachments/20070929/9f5aad99/attachment.obj From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Sep 29 19:46:00 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 29 Sep 2007 19:46:00 +0900 Subject: [Tomoyo-dev 594] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <6331.163.135.10.35.1190946764.squirrel@webmail.knlab.com> References: <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> <6331.163.135.10.35.1190946764.squirrel@webmail.knlab.com> Message-ID: <200709291945.EHH35920.PZWFNPPtGPEtUSN@I-love.SAKURA.ne.jp> > > Ubuntu 6.10 です。エラーメッセージは忘れました。 Ubuntu で実行したら以下のようなエラーでした。 [: 行番号: ==: unexpected operator 比較演算子を == ではなく = や -eq にしないといけないようです。 == を = にして #! /bin/sh で実行すると、 今度は read でタイムアウトを使えなくなってしまいました。 これは、 /bin/sh には read [-p prompt] [-r] variable [...] のようにタイムアウト指定が存在しないのに対し、 /bin/bash には read [-ers] [-u fd] [-t timeout] [-a aname] [-p prompt] [-n nchars] [-d delim] [name ...] のように存在しているためのようです。 > 参考までにbashの何の機能を使用されたのでしょうか？ /sbin/ccs-init に関しては、 /bin/sh で実現できないのは read のタイムアウト機能だけかな？ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Sep 29 20:02:07 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 29 Sep 2007 20:02:07 +0900 Subject: [Tomoyo-dev 595] Re: =?iso-2022-jp?b?Y2NzdG9vbHMgTWFrZWZpbGUgGyRCIUobKEJSZTogYWxp?= =?iso-2022-jp?b?ZW4gGyRCJFskKxsoQg==?= In-Reply-To: <20070929151655.c4b49037.henrich@debian.or.jp> References: <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> <20070926225921.b32b6dcf.henrich@debian.or.jp> <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> <20070927002415.50a2b04a.henrich@debian.or.jp> <20070929151655.c4b49037.henrich@debian.or.jp> Message-ID: <200709292002.CDJ82307.NENtPSZPWGFPUPt@I-love.SAKURA.ne.jp> > 　＃gcc -O2 ではなく -O3 なのは何か理由があります？ 私が習慣でずっと -O3 を指定しているだけです。 -O2 と書くのが慣例なんでしょうか？ 手元の GCC Quick Reference Guide には -O3 は Aggressive GCC optimization と書かれていますが、 -O3 だとコンパイラが認識しないとか正しくないコードを生成してしまうとかいうことがあるのでしょうか？ 私は一度も遭遇したことはないのですが。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Sep 29 20:06:22 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 29 Sep 2007 20:06:22 +0900 Subject: [Tomoyo-dev 596] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <20070929141455.4d6c6405.henrich@debian.or.jp> References: <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> <20070929141455.4d6c6405.henrich@debian.or.jp> Message-ID: <200709292006.EGH73452.GWPZSPPFtNEtPUN@I-love.SAKURA.ne.jp> > 　どうしてもパッケージャーとしての立場からの物言いが多くなりますが > 　ご容赦を。 いえいえ、いろいろアドバイスを戴けて嬉しいです。 > 　利用者が連絡が取れればOKですが、できる限りメールアドレスの方が > 　ありがたいと思います。 どのメールアドレスにします？＞原田さん > 　明示的にライセンスを記載した文章が無いと利用者側は面倒なことに > 　なりますので、同梱してください。（これは先の連絡先より重要です） 了解です。 > 　このページは xml/sgml などから生成でしょうか？もしそうなら man に > 　流用したいと思っています。 ドキュメントは全部テキストエディタで HTML 形式で手書きしています。 man ページの作り方を勉強しないといけないなぁ。 From haradats ＠ gmail.com Sat Sep 29 20:37:41 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Sat, 29 Sep 2007 20:37:41 +0900 Subject: [Tomoyo-dev 597] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <200709292006.EGH73452.GWPZSPPFtNEtPUN@I-love.SAKURA.ne.jp> References: <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> <20070929141455.4d6c6405.henrich@debian.or.jp> <200709292006.EGH73452.GWPZSPPFtNEtPUN@I-love.SAKURA.ne.jp> Message-ID: <9d732d950709290437k2f28bffdk62bfc9634ef51237@mail.gmail.com> 07/09/29 に Tetsuo Handa さんは書きました: > > 利用者が連絡が取れればOKですが、できる限りメールアドレスの方が > > ありがたいと思います。 > どのメールアドレスにします？＞原田さん 半田さんのデータのアドレスにしましょうか。それ以外、 例えば半田さんの個人アドレスでも問題はありません。 「変わらない」という意味ではSourceForge.jpのアドレスを 書いておいて、転送設定をしておくのも良いかも しれません。 > > 明示的にライセンスを記載した文章が無いと利用者側は面倒なことに > > なりますので、同梱してください。（これは先の連絡先より重要です） > 了解です。 > > > このページは xml/sgml などから生成でしょうか？もしそうなら man に > > 流用したいと思っています。 > ドキュメントは全部テキストエディタで HTML 形式で手書きしています。 > man ページの作り方を勉強しないといけないなぁ。 -- Toshiharu Harada haradats ＠ gmail.com From henrich ＠ debian.or.jp Sat Sep 29 21:06:40 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sat, 29 Sep 2007 21:06:40 +0900 Subject: [Tomoyo-dev 598] Re: =?iso-2022-jp?b?Y2NzdG9vbHMbJEIkTj0kQDVEczBGGyhC?= In-Reply-To: <9d732d950709271854x3e2dbbe5o52e7a6b91b2b3c97@mail.gmail.com> References: <9d732d950709271854x3e2dbbe5o52e7a6b91b2b3c97@mail.gmail.com> Message-ID: <20070929210640.486faa06.henrich@debian.or.jp> 　やまねです。 　＃こちらの投稿を見逃したまま Makefile の修正案出してました。 On Fri, 28 Sep 2007 10:54:05 +0900 "Toshiharu Harada" wrote: > ・syaoran, cerberusをallに含める必要はないのでは？ 　含める必要が無い理由はなんでしょうか？ 　＃背景が分かっていないので教えていただけるとありがたいです。 　あと私は 　・ターゲットを幾つもべたがきしてるのはよくないので、最初にまとめて 　　定義してそれを使いまわす形にする 　ようにした方がいいと思います（で、先に投稿した Makefile になる） 　以下おまけ。 　・sourcefourge に配置する際のファイル名が ccs-tools--.tar.gz 　　となっていますが、ファイルとしては ccstools ですよね。 　　であれば、ccstools--.tar.gz と すればよいのでは 　　ないでしょうか。または、ccstools というファイル名だけでは 　　何起源のツールかよく分からないので、tomoyo-ccstools などと 　　接頭詞的に tomoyo- と付けるなどするとわかりやすくていいな、 　　などと思いました。 　　 From henrich ＠ debian.or.jp Sat Sep 29 22:58:12 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sat, 29 Sep 2007 22:58:12 +0900 Subject: [Tomoyo-dev 599] =?iso-2022-jp?b?L2Jpbi9zaCAbJEIkRzUtPVIbKEIgKFJlOiBhbGllbiA=?= =?iso-2022-jp?b?GyRCJFskKxsoQik=?= In-Reply-To: <200709291945.EHH35920.PZWFNPPtGPEtUSN@I-love.SAKURA.ne.jp> References: <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> <6331.163.135.10.35.1190946764.squirrel@webmail.knlab.com> <200709291945.EHH35920.PZWFNPPtGPEtUSN@I-love.SAKURA.ne.jp> Message-ID: <20070929225812.0c5b2ae6.henrich@debian.or.jp> On Sat, 29 Sep 2007 19:46:00 +0900 Tetsuo Handa wrote: > /sbin/ccs-init に関しては、 /bin/sh で実現できないのは read のタイムアウト機能だけかな？ 　ではそこだけ残してとりあえず sh 互換にしてしまいません？ 　 From henrich ＠ debian.or.jp Sat Sep 29 22:32:12 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sat, 29 Sep 2007 22:32:12 +0900 Subject: [Tomoyo-dev 600] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <9292c1390709271643n6f5e9fackc99c6d33eed9bfbf@mail.gmail.com> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> <20070926225921.b32b6dcf.henrich@debian.or.jp> <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <9292c1390709271643n6f5e9fackc99c6d33eed9bfbf@mail.gmail.com> Message-ID: <20070929223212.530e7788.henrich@debian.or.jp> On Fri, 28 Sep 2007 08:43:28 +0900 hito wrote: > 余談にコメントするのも大変アレな感じですが、ユーザランドにある > パッケージと異なり、kernel packageは非互換（Ubuntu的な追加の > デザインがあったり）で、DebianのMainに入れてもUbuntuの > Universeには入りません……。 　別に何の問題もないと思います :-)＜余談にコメント 　確かにカーネル周りだとそうなりますね。仰る通りです。 　 From henrich ＠ debian.or.jp Sun Sep 30 00:24:37 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sun, 30 Sep 2007 00:24:37 +0900 Subject: [Tomoyo-dev 601] =?iso-2022-jp?b?bWFuIBskQiRLJEQkJCRGIUobKEJSZTogYWxpZW4g?= =?iso-2022-jp?b?GyRCJFskKxsoQg==?= In-Reply-To: <200709292006.EGH73452.GWPZSPPFtNEtPUN@I-love.SAKURA.ne.jp> References: <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> <20070929141455.4d6c6405.henrich@debian.or.jp> <200709292006.EGH73452.GWPZSPPFtNEtPUN@I-love.SAKURA.ne.jp> Message-ID: <20070930002437.a21e5e60.henrich@debian.or.jp> On Sat, 29 Sep 2007 20:06:22 +0900 Tetsuo Handa wrote: > > 　このページは xml/sgml などから生成でしょうか？もしそうなら man に > > 　流用したいと思っています。 > ドキュメントは全部テキストエディタで HTML 形式で手書きしています。 > man ページの作り方を勉強しないといけないなぁ。 　sgml/xml 形式で記述して docbook で HTML や man に変換というのが一番 　スマートそうです（今更 nroff とか生書きする必要もありますまい）。 　＃知識として知っているだけで実際にやっている訳では有りませんので、 　　具体例は勘弁下さい ;-) From haradats ＠ gmail.com Sun Sep 30 09:24:12 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Sun, 30 Sep 2007 09:24:12 +0900 Subject: [Tomoyo-dev 602] Re: =?iso-2022-jp?b?Y2NzdG9vbHMbJEIkTj0kQDVEczBGGyhC?= In-Reply-To: <20070929210640.486faa06.henrich@debian.or.jp> References: <9d732d950709271854x3e2dbbe5o52e7a6b91b2b3c97@mail.gmail.com> <20070929210640.486faa06.henrich@debian.or.jp> Message-ID: <9d732d950709291724j596064afk4fe3120b133d1a57@mail.gmail.com> 07/09/29 に Hideki Yamane さんは書きました: > On Fri, 28 Sep 2007 10:54:05 +0900 > "Toshiharu Harada" wrote: > > ・syaoran, cerberusをallに含める必要はないのでは？ > > 含める必要が無い理由はなんでしょうか？ > ＃背景が分かっていないので教えていただけるとありがたいです。 まず、syaoranから。syaoranの内容（全体像）については 下記が一番わかりやすいはずです。 http://kumaneko-sakura.sblo.jp/article/301456.html syaoran（ファイルシステム）は、TOMOYO Linuxとは 独立に利用することができます。toolsの makesyaoranconfは、syaoranの設定ファイルである syaoran.confを生成するためのものです。 （熊猫さくらの上記ブログのsyaoran.confのポリシー例リンクが 切れているので修正が必要です） ということで、makesyaoranconfは、必ずしもTOMOYO Linux ユーザの全てが使うものではないので、オプショナルの ツールとして分類して、コンパイルは必要な人だけに したらと思ったわけです。 次にcerberusですが、こちらはTOMOYO Linuxの「機能」では なく、「使い方」の総称です（機能ではないので、 configメニューにも現れません）。cerberusの説明としては、 http://kumaneko-sakura.sblo.jp/article/286949.html および上記から参照されている論文を参照下さい。 cerberusというのは簡単に言うと、ログインした後に強制アクセス 制御を利用して（cerberusはTOMOYOの機能を前提とします）、 認証強化のツールを多段でカスタマイズするというものなので、 決まったツールはありません。groovy他のツールは、その使い方の 具体例、サンプルプログラムです。 私の個人的な考え方としては、ユーザが必要としないものを コンパイルさせるのはどうかと思うので提案した次第です。 提案後半田さんと話をしたところ、「提供している機能は、 groovy等も含めてすぐに利用できるようにしたい」ということでした。 それはそのような考え方もあると思うので、cerberus/mailauthの コンパイルのためにssl-devを導入しなくても良いように してもらえばそれで良いかと思います。 > あと私は > ・ターゲットを幾つもべたがきしてるのはよくないので、最初にまとめて > 定義してそれを使いまわす形にする > ようにした方がいいと思います（で、先に投稿した Makefile になる） > > 以下おまけ。 > > ・sourcefourge に配置する際のファイル名が ccs-tools--.tar.gz > となっていますが、ファイルとしては ccstools ですよね。 > であれば、ccstools--.tar.gz と すればよいのでは > ないでしょうか。または、ccstools というファイル名だけでは > 何起源のツールかよく分からないので、tomoyo-ccstools などと > 接頭詞的に tomoyo- と付けるなどするとわかりやすくていいな、 > などと思いました。 -- Toshiharu Harada haradats ＠ gmail.com From haradats ＠ gmail.com Sun Sep 30 09:25:39 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Sun, 30 Sep 2007 09:25:39 +0900 Subject: [Tomoyo-dev 603] Re: =?iso-2022-jp?b?Y2NzdG9vbHMbJEIkTj0kQDVEczBGGyhC?= In-Reply-To: <9d732d950709291724j596064afk4fe3120b133d1a57@mail.gmail.com> References: <9d732d950709271854x3e2dbbe5o52e7a6b91b2b3c97@mail.gmail.com> <20070929210640.486faa06.henrich@debian.or.jp> <9d732d950709291724j596064afk4fe3120b133d1a57@mail.gmail.com> Message-ID: <9d732d950709291725i4b392d4bt17a4659c5fb065a8@mail.gmail.com> 07/09/30 に Toshiharu Harada さんは書きました: > 07/09/29 に Hideki Yamane さんは書きました: > > On Fri, 28 Sep 2007 10:54:05 +0900 > > "Toshiharu Harada" wrote: > > > ・syaoran, cerberusをallに含める必要はないのでは？ > > > > 含める必要が無い理由はなんでしょうか？ > > ＃背景が分かっていないので教えていただけるとありがたいです。 > > まず、syaoranから。syaoranの内容（全体像）については > 下記が一番わかりやすいはずです。 > http://kumaneko-sakura.sblo.jp/article/301456.html プロジェクトのリファレンスの該当部分も貼っておきます。 http://tomoyo.sourceforge.jp/ja/1.5.x/compile.html http://tomoyo.sourceforge.jp/ja/1.5.x/policy-syaoran.html -- Toshiharu Harada haradats ＠ gmail.com From haradats ＠ gmail.com Sun Sep 30 09:44:16 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Sun, 30 Sep 2007 09:44:16 +0900 Subject: [Tomoyo-dev 604] Re: =?iso-2022-jp?b?L2Jpbi9zaCAbJEIkRzUtPVIbKEIgKFJlOiBhbGllbiA=?= =?iso-2022-jp?b?GyRCJFskKxsoQik=?= In-Reply-To: <20070929225812.0c5b2ae6.henrich@debian.or.jp> References: <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> <6331.163.135.10.35.1190946764.squirrel@webmail.knlab.com> <200709291945.EHH35920.PZWFNPPtGPEtUSN@I-love.SAKURA.ne.jp> <20070929225812.0c5b2ae6.henrich@debian.or.jp> Message-ID: <9d732d950709291744m6c3ec57at4f13922f5f18e169@mail.gmail.com> 07/09/29 に Hideki Yamane さんは書きました: > On Sat, 29 Sep 2007 19:46:00 +0900 > Tetsuo Handa wrote: > > /sbin/ccs-init に関しては、 /bin/sh で実現できないのは read のタイムアウト機能だけかな？ > > ではそこだけ残してとりあえず sh 互換にしてしまいません？ ちょうどそのread（boot時のプロンプト表示とタイムアウト）について、 たった今、Open Discussionフォーラムに下記書き込みがありました。 1. make TOMOYO boot quickly it would be a waste of time to wait 10 seconds for the disable input at boot time: TOMOYO Linux: Enter 'disable' within 10 seconds to disable TOMOYO Linux. TOMOYO Linux> maybe a boot parameter like tomoyo=noprompt to bypass disable prompt with TOMOYO enabled by default: # setup GRUB menu title LFS 6.3 Kernel 2.6.22.9-cfs-v22-ccs kernel (hd0,7)/boot/lfskernel-2.6.22.9-cfs-v22-ccs root=/dev/hda8 vga=791 video=vesafb:ywrap ,mtrr acpi=off tomoyo=noprompt -- Toshiharu Harada haradats ＠ gmail.com From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sun Sep 30 12:34:57 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 30 Sep 2007 12:34:57 +0900 Subject: [Tomoyo-dev 605] Re: =?iso-2022-jp?b?Y2NzdG9vbHMgGyRCJE49JEA1RHMwRhsoQg==?= In-Reply-To: <9d732d950709291724j596064afk4fe3120b133d1a57@mail.gmail.com> References: <9d732d950709271854x3e2dbbe5o52e7a6b91b2b3c97@mail.gmail.com> <20070929210640.486faa06.henrich@debian.or.jp> <9d732d950709291724j596064afk4fe3120b133d1a57@mail.gmail.com> Message-ID: <200709301234.EFI12487.tEWtPPUSFZPNGNP@I-love.SAKURA.ne.jp> > 私の個人的な考え方としては、ユーザが必要としないものを > コンパイルさせるのはどうかと思うので提案した次第です。 > 提案後半田さんと話をしたところ、「提供している機能は、 > groovy等も含めてすぐに利用できるようにしたい」ということでした。 > それはそのような考え方もあると思うので、cerberus/mailauthの > コンパイルのためにssl-devを導入しなくても良いように > してもらえばそれで良いかと思います。 mailauth.c のソースを見ればわかるとおり、 疑似乱数を生成するために md5 を利用しているだけなので openssl のライブラリでなければいけないという理由はありません。 md5 ではなく sha1 などでも良いですし、 srand() + rand() を /dev/urandom で置き換えるだけでも良いかもしれません。 （ /dev/urandom が全てのシステムで使えるかどうか心配ではありますが。） From haradats ＠ gmail.com Fri Sep 28 17:34:53 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Fri, 28 Sep 2007 08:34:53 -0000 Subject: [Tomoyo-dev 589] TOMOYO on LFS Message-ID: <9d732d950709280134p2c82c042h1c89b2a1f59e0030@mail.gmail.com> 最近、SourceForge.jpのOpen Discussionのフォーラムに 英語での書き込みがありました。 内容は、"LFS (Linux From Scratch)"でTOMOYO Linuxを使いたい、 ということだったのですが、さきほど無事動作したという 報告がありました。 LFSについては、 http://www.linuxfromscratch.org/ フォーラムは http://sourceforge.jp/forum/forum.php?forum_id=11352 （スレッドまでURLに含めるとスパムに攻撃されるので トップレベルです。LFSで探してください） 親切にも手順をまとめてくれているので、近いうちに プロジェクトのwiki/webに追加しようと思っています。 今後、海外の方も利用して欲しいので、tomoyo-usersと tomoyo-devについて、日本語以外に英語を追加し、 デフォルトの言語を英語に変更しました。各ユーザは 表示する言語を選択できるので特に支障ないはずですが、 何かお気づきの点があればお知らせ下さい。 -- Toshiharu Harada haradats ＠ gmail.com From nez ＠ samba.gr.jp Sat Sep 29 05:14:49 2007 From: nez ＠ samba.gr.jp (Kensuke Nezu) Date: Fri, 28 Sep 2007 20:14:49 -0000 Subject: [Tomoyo-dev 590] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <200709280201.l8S21qia075749@www262.sakura.ne.jp> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp><200709230737.l8N7bnAK030913@www262.sakura.ne.jp><20070926225921.b32b6dcf.henrich@debian.or.jp><9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com><20070927002415.50a2b04a.henrich@debian.or.jp><200709261611.l8QGB18d036994@www262.sakura.ne.jp><20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> Message-ID: <6331.163.135.10.35.1190946764.squirrel@webmail.knlab.com> 根津です。 On 2007年 9月 28日 (金) 11:01, from-tomoyo-dev ＠ i-love.sakura.ne.jp wrote: >> > > 　　が #! /bin/bash になっている。bash 依存よくないっす >> > 現在サポートしているディストリビューションの中に >> > /bin/sh だと動かないものがあったので /bin/bash を使っています。 >> >> 　それは具体的にはどのdistroでどんな症状だったのでしょう？ >> 　＃興味から聞いています。 > > Ubuntu 6.10 です。エラーメッセージは忘れました。 > /bin/sh は大抵 /bin/bash へのシンボリックリンクになっていますが、 > たまに /bin/dash へのシンボリックリンクになっている環境があります。 > /bin/sh の仕様だと思って書いたものが実は /bin/bash でないと使えない > というケースに Ubuntu で遭遇したので、 /bin/sh ではなく /bin/bash と > 明示するようにしました。 それは、シェルスクリプトをshのスペックで記述するように修正する方が いいんじゃないですか？具体的に、bashのどの機能が必須だからbashを 明示指定したかによるとは思いますが・・・。 参考までにbashの何の機能を使用されたのでしょうか？ -- ------ 根津 研介 日本Sambaユーザ会/NTTデータ先端技術（株） Microsoft MVP for Windows Security(Apr 2005 - Mar 2008) 802.11セキュリティサイト：http://www.famm.jp/wireless ※「SELinuxシステム管理―セキュアOSの基礎と運用」 http://www.oreilly.co.jp/books/4873112257/ ※「実用SSH第２版−セキュアシェル徹底活用ガイド」 http://www.oreilly.co.jp/books/4873112877/ From henrich ＠ debian.or.jp Sat Sep 29 17:28:03 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sat, 29 Sep 2007 08:28:03 -0000 Subject: [Tomoyo-dev 591] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <200709280201.l8S21qia075749@www262.sakura.ne.jp> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> <20070926225921.b32b6dcf.henrich@debian.or.jp> <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> Message-ID: <20070929141455.4d6c6405.henrich@debian.or.jp> 　やまねです。 　どうしてもパッケージャーとしての立場からの物言いが多くなりますが 　ご容赦を。 On Fri, 28 Sep 2007 11:01:52 +0900 from-tomoyo-dev ＠ i-love.sakura.ne.jp wrote: > Ubuntu 6.10 です。エラーメッセージは忘れました。 > /bin/sh は大抵 /bin/bash へのシンボリックリンクになっていますが、 > たまに /bin/dash へのシンボリックリンクになっている環境があります。 　なるほど。そうですね。 > /bin/sh の仕様だと思って書いたものが実は /bin/bash でないと使えない > というケースに Ubuntu で遭遇したので、 /bin/sh ではなく /bin/bash と > 明示するようにしました。 　Debian Policy 上は、 　・sh 準拠（これが望ましい） 　・ダメなら bash と明示 　でした。なので通ることは通りますね。 > > > > 　・ccstools の copyright と作者の連絡先はどこになるんでしょう? > > > > 　copyright は (c) 2005-2007 NTT DATA Corporation でしょうか？ > > 　作者連絡先は…どうするのが良いでしょうか？ > 連絡先がメールアドレスではなくＵＲＬというのは不可ですか？ 　利用者が連絡が取れればOKですが、できる限りメールアドレスの方が 　ありがたいと思います。 　＃名刺に住所だけ書いてあって、連絡取ろうとすると苦労する、みたいな。 　　会社なので、色々手続きが面倒なことがある、などということであるとも 　　思いますので無理強いというわけではありません。 > > > > 　・GPL は 2 のみでしょうか。それとも 2 or later（どこかに書いてあるかも） > カーネルソースと同じ扱いだと思います。 　明示的にライセンスを記載した文章が無いと利用者側は面倒なことに 　なりますので、同梱してください。（これは先の連絡先より重要です） 　 > > 　使い方はこれをよめ、というドキュメントはどれになりますか？ > http://tomoyo.sourceforge.jp/en/1.5.x/tools-doc.html です。 　ありがとうございます。了解しました。 　このページは xml/sgml などから生成でしょうか？もしそうなら man に 　流用したいと思っています。 From henrich ＠ debian.or.jp Sat Sep 29 17:28:04 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sat, 29 Sep 2007 08:28:04 -0000 Subject: [Tomoyo-dev 592] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <6331.163.135.10.35.1190946764.squirrel@webmail.knlab.com> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> <20070926225921.b32b6dcf.henrich@debian.or.jp> <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> <6331.163.135.10.35.1190946764.squirrel@webmail.knlab.com> Message-ID: <20070929141605.8168f3f2.henrich@debian.or.jp> 　やまねです。 On Fri, 28 Sep 2007 11:32:44 +0900 (JST) "Kensuke Nezu" wrote: > 根津です。 　 　ども。 > それは、シェルスクリプトをshのスペックで記述するように修正する方が > いいんじゃないですか？具体的に、bashのどの機能が必須だからbashを > 明示指定したかによるとは思いますが・・・。 　その通りですね。 From henrich ＠ debian.or.jp Sat Sep 29 17:28:05 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sat, 29 Sep 2007 08:28:05 -0000 Subject: [Tomoyo-dev 593] =?iso-2022-jp?b?Y2NzdG9vbHMgTWFrZWZpbGUgGyRCIUobKEJSZTogYWxpZW4g?= =?iso-2022-jp?b?GyRCJFskKxsoQg==?= In-Reply-To: <20070927002415.50a2b04a.henrich@debian.or.jp> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> <20070926225921.b32b6dcf.henrich@debian.or.jp> <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> <20070927002415.50a2b04a.henrich@debian.or.jp> Message-ID: <20070929151655.c4b49037.henrich@debian.or.jp> 　やまねです。 On Thu, 27 Sep 2007 00:24:15 +0900 Hideki Yamane wrote: > 　・Makefile が結構ベタがきかなーと。適宜改行が入ると見やすいですね。 　いうだけでは何なので、手元ではこんな風にしてみました。 　＃gcc -O2 ではなく -O3 なのは何か理由があります？ -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: Makefile.dpatch 型: application/octet-stream サイズ: 4692 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/attachments/20070929/9f5aad99/attachment-0001.obj From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Sep 29 19:46:12 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 29 Sep 2007 10:46:12 -0000 Subject: [Tomoyo-dev 594] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <6331.163.135.10.35.1190946764.squirrel@webmail.knlab.com> References: <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> <6331.163.135.10.35.1190946764.squirrel@webmail.knlab.com> Message-ID: <200709291945.EHH35920.PZWFNPPtGPEtUSN@I-love.SAKURA.ne.jp> > > Ubuntu 6.10 です。エラーメッセージは忘れました。 Ubuntu で実行したら以下のようなエラーでした。 [: 行番号: ==: unexpected operator 比較演算子を == ではなく = や -eq にしないといけないようです。 == を = にして #! /bin/sh で実行すると、 今度は read でタイムアウトを使えなくなってしまいました。 これは、 /bin/sh には read [-p prompt] [-r] variable [...] のようにタイムアウト指定が存在しないのに対し、 /bin/bash には read [-ers] [-u fd] [-t timeout] [-a aname] [-p prompt] [-n nchars] [-d delim] [name ...] のように存在しているためのようです。 > 参考までにbashの何の機能を使用されたのでしょうか？ /sbin/ccs-init に関しては、 /bin/sh で実現できないのは read のタイムアウト機能だけかな？ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Sep 29 20:02:17 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 29 Sep 2007 11:02:17 -0000 Subject: [Tomoyo-dev 595] Re: =?iso-2022-jp?b?Y2NzdG9vbHMgTWFrZWZpbGUgGyRCIUobKEJSZTogYWxp?= =?iso-2022-jp?b?ZW4gGyRCJFskKxsoQg==?= In-Reply-To: <20070929151655.c4b49037.henrich@debian.or.jp> References: <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> <20070926225921.b32b6dcf.henrich@debian.or.jp> <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> <20070927002415.50a2b04a.henrich@debian.or.jp> <20070929151655.c4b49037.henrich@debian.or.jp> Message-ID: <200709292002.CDJ82307.NENtPSZPWGFPUPt@I-love.SAKURA.ne.jp> > 　＃gcc -O2 ではなく -O3 なのは何か理由があります？ 私が習慣でずっと -O3 を指定しているだけです。 -O2 と書くのが慣例なんでしょうか？ 手元の GCC Quick Reference Guide には -O3 は Aggressive GCC optimization と書かれていますが、 -O3 だとコンパイラが認識しないとか正しくないコードを生成してしまうとかいうことがあるのでしょうか？ 私は一度も遭遇したことはないのですが。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Sep 29 20:06:32 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 29 Sep 2007 11:06:32 -0000 Subject: [Tomoyo-dev 596] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <20070929141455.4d6c6405.henrich@debian.or.jp> References: <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> <20070929141455.4d6c6405.henrich@debian.or.jp> Message-ID: <200709292006.EGH73452.GWPZSPPFtNEtPUN@I-love.SAKURA.ne.jp> > 　どうしてもパッケージャーとしての立場からの物言いが多くなりますが > 　ご容赦を。 いえいえ、いろいろアドバイスを戴けて嬉しいです。 > 　利用者が連絡が取れればOKですが、できる限りメールアドレスの方が > 　ありがたいと思います。 どのメールアドレスにします？＞原田さん > 　明示的にライセンスを記載した文章が無いと利用者側は面倒なことに > 　なりますので、同梱してください。（これは先の連絡先より重要です） 了解です。 > 　このページは xml/sgml などから生成でしょうか？もしそうなら man に > 　流用したいと思っています。 ドキュメントは全部テキストエディタで HTML 形式で手書きしています。 man ページの作り方を勉強しないといけないなぁ。 From haradats ＠ gmail.com Sat Sep 29 20:37:53 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Sat, 29 Sep 2007 11:37:53 -0000 Subject: [Tomoyo-dev 597] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <200709292006.EGH73452.GWPZSPPFtNEtPUN@I-love.SAKURA.ne.jp> References: <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> <20070929141455.4d6c6405.henrich@debian.or.jp> <200709292006.EGH73452.GWPZSPPFtNEtPUN@I-love.SAKURA.ne.jp> Message-ID: <9d732d950709290437k2f28bffdk62bfc9634ef51237@mail.gmail.com> 07/09/29 に Tetsuo Handa さんは書きました: > > 利用者が連絡が取れればOKですが、できる限りメールアドレスの方が > > ありがたいと思います。 > どのメールアドレスにします？＞原田さん 半田さんのデータのアドレスにしましょうか。それ以外、 例えば半田さんの個人アドレスでも問題はありません。 「変わらない」という意味ではSourceForge.jpのアドレスを 書いておいて、転送設定をしておくのも良いかも しれません。 > > 明示的にライセンスを記載した文章が無いと利用者側は面倒なことに > > なりますので、同梱してください。（これは先の連絡先より重要です） > 了解です。 > > > このページは xml/sgml などから生成でしょうか？もしそうなら man に > > 流用したいと思っています。 > ドキュメントは全部テキストエディタで HTML 形式で手書きしています。 > man ページの作り方を勉強しないといけないなぁ。 -- Toshiharu Harada haradats ＠ gmail.com From henrich ＠ debian.or.jp Sun Sep 30 00:03:30 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sat, 29 Sep 2007 15:03:30 -0000 Subject: [Tomoyo-dev 598] Re: =?iso-2022-jp?b?Y2NzdG9vbHMbJEIkTj0kQDVEczBGGyhC?= In-Reply-To: <9d732d950709271854x3e2dbbe5o52e7a6b91b2b3c97@mail.gmail.com> References: <9d732d950709271854x3e2dbbe5o52e7a6b91b2b3c97@mail.gmail.com> Message-ID: <20070929210640.486faa06.henrich@debian.or.jp> 　やまねです。 　＃こちらの投稿を見逃したまま Makefile の修正案出してました。 On Fri, 28 Sep 2007 10:54:05 +0900 "Toshiharu Harada" wrote: > ・syaoran, cerberusをallに含める必要はないのでは？ 　含める必要が無い理由はなんでしょうか？ 　＃背景が分かっていないので教えていただけるとありがたいです。 　あと私は 　・ターゲットを幾つもべたがきしてるのはよくないので、最初にまとめて 　　定義してそれを使いまわす形にする 　ようにした方がいいと思います（で、先に投稿した Makefile になる） 　以下おまけ。 　・sourcefourge に配置する際のファイル名が ccs-tools--.tar.gz 　　となっていますが、ファイルとしては ccstools ですよね。 　　であれば、ccstools--.tar.gz と すればよいのでは 　　ないでしょうか。または、ccstools というファイル名だけでは 　　何起源のツールかよく分からないので、tomoyo-ccstools などと 　　接頭詞的に tomoyo- と付けるなどするとわかりやすくていいな、 　　などと思いました。 　　 From henrich ＠ debian.or.jp Sun Sep 30 00:03:30 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sat, 29 Sep 2007 15:03:30 -0000 Subject: [Tomoyo-dev 599] =?iso-2022-jp?b?L2Jpbi9zaCAbJEIkRzUtPVIbKEIgKFJlOiBhbGllbiA=?= =?iso-2022-jp?b?GyRCJFskKxsoQik=?= In-Reply-To: <200709291945.EHH35920.PZWFNPPtGPEtUSN@I-love.SAKURA.ne.jp> References: <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> <6331.163.135.10.35.1190946764.squirrel@webmail.knlab.com> <200709291945.EHH35920.PZWFNPPtGPEtUSN@I-love.SAKURA.ne.jp> Message-ID: <20070929225812.0c5b2ae6.henrich@debian.or.jp> On Sat, 29 Sep 2007 19:46:00 +0900 Tetsuo Handa wrote: > /sbin/ccs-init に関しては、 /bin/sh で実現できないのは read のタイムアウト機能だけかな？ 　ではそこだけ残してとりあえず sh 互換にしてしまいません？ 　 From henrich ＠ debian.or.jp Sun Sep 30 00:03:30 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sat, 29 Sep 2007 15:03:30 -0000 Subject: [Tomoyo-dev 600] Re: =?iso-2022-jp?b?YWxpZW4gGyRCJFskKxsoQg==?= In-Reply-To: <9292c1390709271643n6f5e9fackc99c6d33eed9bfbf@mail.gmail.com> References: <200709210643.l8L6hvAw076555@www262.sakura.ne.jp> <200709230737.l8N7bnAK030913@www262.sakura.ne.jp> <20070926225921.b32b6dcf.henrich@debian.or.jp> <9d732d950709260724q79456af0r804936dfa117703b@mail.gmail.com> <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <9292c1390709271643n6f5e9fackc99c6d33eed9bfbf@mail.gmail.com> Message-ID: <20070929223212.530e7788.henrich@debian.or.jp> On Fri, 28 Sep 2007 08:43:28 +0900 hito wrote: > 余談にコメントするのも大変アレな感じですが、ユーザランドにある > パッケージと異なり、kernel packageは非互換（Ubuntu的な追加の > デザインがあったり）で、DebianのMainに入れてもUbuntuの > Universeには入りません……。 　別に何の問題もないと思います :-)＜余談にコメント 　確かにカーネル周りだとそうなりますね。仰る通りです。 　 From henrich ＠ debian.or.jp Sun Sep 30 00:57:25 2007 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sat, 29 Sep 2007 15:57:25 -0000 Subject: [Tomoyo-dev 601] =?iso-2022-jp?b?bWFuIBskQiRLJEQkJCRGIUobKEJSZTogYWxpZW4g?= =?iso-2022-jp?b?GyRCJFskKxsoQg==?= In-Reply-To: <200709292006.EGH73452.GWPZSPPFtNEtPUN@I-love.SAKURA.ne.jp> References: <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> <20070929141455.4d6c6405.henrich@debian.or.jp> <200709292006.EGH73452.GWPZSPPFtNEtPUN@I-love.SAKURA.ne.jp> Message-ID: <20070930002437.a21e5e60.henrich@debian.or.jp> On Sat, 29 Sep 2007 20:06:22 +0900 Tetsuo Handa wrote: > > 　このページは xml/sgml などから生成でしょうか？もしそうなら man に > > 　流用したいと思っています。 > ドキュメントは全部テキストエディタで HTML 形式で手書きしています。 > man ページの作り方を勉強しないといけないなぁ。 　sgml/xml 形式で記述して docbook で HTML や man に変換というのが一番 　スマートそうです（今更 nroff とか生書きする必要もありますまい）。 　＃知識として知っているだけで実際にやっている訳では有りませんので、 　　具体例は勘弁下さい ;-) From haradats ＠ gmail.com Sun Sep 30 09:24:22 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Sun, 30 Sep 2007 00:24:22 -0000 Subject: [Tomoyo-dev 602] Re: =?iso-2022-jp?b?Y2NzdG9vbHMbJEIkTj0kQDVEczBGGyhC?= In-Reply-To: <20070929210640.486faa06.henrich@debian.or.jp> References: <9d732d950709271854x3e2dbbe5o52e7a6b91b2b3c97@mail.gmail.com> <20070929210640.486faa06.henrich@debian.or.jp> Message-ID: <9d732d950709291724j596064afk4fe3120b133d1a57@mail.gmail.com> 07/09/29 に Hideki Yamane さんは書きました: > On Fri, 28 Sep 2007 10:54:05 +0900 > "Toshiharu Harada" wrote: > > ・syaoran, cerberusをallに含める必要はないのでは？ > > 含める必要が無い理由はなんでしょうか？ > ＃背景が分かっていないので教えていただけるとありがたいです。 まず、syaoranから。syaoranの内容（全体像）については 下記が一番わかりやすいはずです。 http://kumaneko-sakura.sblo.jp/article/301456.html syaoran（ファイルシステム）は、TOMOYO Linuxとは 独立に利用することができます。toolsの makesyaoranconfは、syaoranの設定ファイルである syaoran.confを生成するためのものです。 （熊猫さくらの上記ブログのsyaoran.confのポリシー例リンクが 切れているので修正が必要です） ということで、makesyaoranconfは、必ずしもTOMOYO Linux ユーザの全てが使うものではないので、オプショナルの ツールとして分類して、コンパイルは必要な人だけに したらと思ったわけです。 次にcerberusですが、こちらはTOMOYO Linuxの「機能」では なく、「使い方」の総称です（機能ではないので、 configメニューにも現れません）。cerberusの説明としては、 http://kumaneko-sakura.sblo.jp/article/286949.html および上記から参照されている論文を参照下さい。 cerberusというのは簡単に言うと、ログインした後に強制アクセス 制御を利用して（cerberusはTOMOYOの機能を前提とします）、 認証強化のツールを多段でカスタマイズするというものなので、 決まったツールはありません。groovy他のツールは、その使い方の 具体例、サンプルプログラムです。 私の個人的な考え方としては、ユーザが必要としないものを コンパイルさせるのはどうかと思うので提案した次第です。 提案後半田さんと話をしたところ、「提供している機能は、 groovy等も含めてすぐに利用できるようにしたい」ということでした。 それはそのような考え方もあると思うので、cerberus/mailauthの コンパイルのためにssl-devを導入しなくても良いように してもらえばそれで良いかと思います。 > あと私は > ・ターゲットを幾つもべたがきしてるのはよくないので、最初にまとめて > 定義してそれを使いまわす形にする > ようにした方がいいと思います（で、先に投稿した Makefile になる） > > 以下おまけ。 > > ・sourcefourge に配置する際のファイル名が ccs-tools--.tar.gz > となっていますが、ファイルとしては ccstools ですよね。 > であれば、ccstools--.tar.gz と すればよいのでは > ないでしょうか。または、ccstools というファイル名だけでは > 何起源のツールかよく分からないので、tomoyo-ccstools などと > 接頭詞的に tomoyo- と付けるなどするとわかりやすくていいな、 > などと思いました。 -- Toshiharu Harada haradats ＠ gmail.com From haradats ＠ gmail.com Sun Sep 30 09:25:52 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Sun, 30 Sep 2007 00:25:52 -0000 Subject: [Tomoyo-dev 603] Re: =?iso-2022-jp?b?Y2NzdG9vbHMbJEIkTj0kQDVEczBGGyhC?= In-Reply-To: <9d732d950709291724j596064afk4fe3120b133d1a57@mail.gmail.com> References: <9d732d950709271854x3e2dbbe5o52e7a6b91b2b3c97@mail.gmail.com> <20070929210640.486faa06.henrich@debian.or.jp> <9d732d950709291724j596064afk4fe3120b133d1a57@mail.gmail.com> Message-ID: <9d732d950709291725i4b392d4bt17a4659c5fb065a8@mail.gmail.com> 07/09/30 に Toshiharu Harada さんは書きました: > 07/09/29 に Hideki Yamane さんは書きました: > > On Fri, 28 Sep 2007 10:54:05 +0900 > > "Toshiharu Harada" wrote: > > > ・syaoran, cerberusをallに含める必要はないのでは？ > > > > 含める必要が無い理由はなんでしょうか？ > > ＃背景が分かっていないので教えていただけるとありがたいです。 > > まず、syaoranから。syaoranの内容（全体像）については > 下記が一番わかりやすいはずです。 > http://kumaneko-sakura.sblo.jp/article/301456.html プロジェクトのリファレンスの該当部分も貼っておきます。 http://tomoyo.sourceforge.jp/ja/1.5.x/compile.html http://tomoyo.sourceforge.jp/ja/1.5.x/policy-syaoran.html -- Toshiharu Harada haradats ＠ gmail.com From haradats ＠ gmail.com Sun Sep 30 09:44:27 2007 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Sun, 30 Sep 2007 00:44:27 -0000 Subject: [Tomoyo-dev 604] Re: =?iso-2022-jp?b?L2Jpbi9zaCAbJEIkRzUtPVIbKEIgKFJlOiBhbGllbiA=?= =?iso-2022-jp?b?GyRCJFskKxsoQik=?= In-Reply-To: <20070929225812.0c5b2ae6.henrich@debian.or.jp> References: <20070927002415.50a2b04a.henrich@debian.or.jp> <200709261611.l8QGB18d036994@www262.sakura.ne.jp> <20070928010343.62321f5f.henrich@debian.or.jp> <200709280201.l8S21qia075749@www262.sakura.ne.jp> <6331.163.135.10.35.1190946764.squirrel@webmail.knlab.com> <200709291945.EHH35920.PZWFNPPtGPEtUSN@I-love.SAKURA.ne.jp> <20070929225812.0c5b2ae6.henrich@debian.or.jp> Message-ID: <9d732d950709291744m6c3ec57at4f13922f5f18e169@mail.gmail.com> 07/09/29 に Hideki Yamane さんは書きました: > On Sat, 29 Sep 2007 19:46:00 +0900 > Tetsuo Handa wrote: > > /sbin/ccs-init に関しては、 /bin/sh で実現できないのは read のタイムアウト機能だけかな？ > > ではそこだけ残してとりあえず sh 互換にしてしまいません？ ちょうどそのread（boot時のプロンプト表示とタイムアウト）について、 たった今、Open Discussionフォーラムに下記書き込みがありました。 1. make TOMOYO boot quickly it would be a waste of time to wait 10 seconds for the disable input at boot time: TOMOYO Linux: Enter 'disable' within 10 seconds to disable TOMOYO Linux. TOMOYO Linux> maybe a boot parameter like tomoyo=noprompt to bypass disable prompt with TOMOYO enabled by default: # setup GRUB menu title LFS 6.3 Kernel 2.6.22.9-cfs-v22-ccs kernel (hd0,7)/boot/lfskernel-2.6.22.9-cfs-v22-ccs root=/dev/hda8 vga=791 video=vesafb:ywrap ,mtrr acpi=off tomoyo=noprompt -- Toshiharu Harada haradats ＠ gmail.com From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sun Sep 30 12:35:08 2007 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 30 Sep 2007 03:35:08 -0000 Subject: [Tomoyo-dev 605] Re: =?iso-2022-jp?b?Y2NzdG9vbHMgGyRCJE49JEA1RHMwRhsoQg==?= In-Reply-To: <9d732d950709291724j596064afk4fe3120b133d1a57@mail.gmail.com> References: <9d732d950709271854x3e2dbbe5o52e7a6b91b2b3c97@mail.gmail.com> <20070929210640.486faa06.henrich@debian.or.jp> <9d732d950709291724j596064afk4fe3120b133d1a57@mail.gmail.com> Message-ID: <200709301234.EFI12487.tEWtPPUSFZPNGNP@I-love.SAKURA.ne.jp> > 私の個人的な考え方としては、ユーザが必要としないものを > コンパイルさせるのはどうかと思うので提案した次第です。 > 提案後半田さんと話をしたところ、「提供している機能は、 > groovy等も含めてすぐに利用できるようにしたい」ということでした。 > それはそのような考え方もあると思うので、cerberus/mailauthの > コンパイルのためにssl-devを導入しなくても良いように > してもらえばそれで良いかと思います。 mailauth.c のソースを見ればわかるとおり、 疑似乱数を生成するために md5 を利用しているだけなので openssl のライブラリでなければいけないという理由はありません。 md5 ではなく sha1 などでも良いですし、 srand() + rand() を /dev/urandom で置き換えるだけでも良いかもしれません。 （ /dev/urandom が全てのシステムで使えるかどうか心配ではありますが。）