Gentoo Weekly Newsletter: 2005年2月14日Gentooフォーラムのプラットフォームとソフトウェアの変更 3週間前のFuture zone(訳)の記事で期待されていたように、 Gentooフォーラムは、新しいハードウェアプラットフォームとアップグレードバージョンのphpBBに切り替えました。 現在動作しているのは素のままのphpBBであり、古いバージョンに対して適用されたパッチはすべて標準として取り込まれ、 フォーラムで以前動作していたもののリリースより機能が豊富になっています。 おまけとして、非英語フォーラムに対するより優れた言語パック、検索エンジンがフォーラム全体をインデックスすることを可能にする絶対パスのリンクによる新しいURIスタイル そして、目に付きにくい点として、モデレータがスレッドに参加できるというような機能があります。 より適当な場所にあるべき文脈から逸脱した投稿をスレッドから強制排除することは、以前はできませんでした。 数少ない問題点としては、切替がうまく行き過ぎて、ユーザの誰も完全に入れ替わってしまったことに気づいていないと言うことです。 問題なく移行してくれたChristian HartmannとLance Albertsonに賞賛の意を表しましょう! Gentooの好きな人にとっては忙しい日々になります。 これから4週間は、展示やカンファレンス、プレゼンテーションが今までにないほど密に詰っています。 予定されているイベントの一覧を示します。開催前の最後の通知として、明日からのボストンで行われるLWEを一番上に書いておきます。
Gentoo Linuxセキュリティチーム -- Thierry Carrezへのインタビュー もし、セキュリティ問題のパターンとLinuxにおける対応を見る習慣があるのなら、 Gentooの警告とこれらの問題に対する対応は、最初の発見後すぐにこれに追従する傾向があることに気づいているでしょう。 実際、Gentoo Linuxセキュリティアナウンス(GLSA、Gentoo Linux Security Announcement)は、 Gentooコミュニティ外のセキュリティ通知や修正状況においてさえ、頻繁に引用されています。 この対応の良さに対する評判は、専門のセキュリティ対策センターをサポートする商用部門を持たないコミュニティでは、珍しい特徴です。 Thierry Carrez (koon)は、Gentooセキュリティチームの運営上のマネージャであり、 チームが効果的にセキュリティ問題を特定し、対処するための慣例について説明するために親切にも時間を割いてくれました。 セキュリティ上の不具合を特定し修正する過程の概要を説明していただけますか？ どのような手順が必要ですか？誰がそれらを行うのでしょうか？どのようなツールが必要ですか？ わたしたちは、セキュリティバグを扱う際には脆弱性取り扱いポリシー(Vulnerability Treatment Policy)に従っています。 簡単に言うと、一般的な脆弱性は、ユーザ、セキュリティ偵察者、セキュリティ開発者最初に発見した人間が報告するようになっています。 ときどき私たちは、極秘のルートから通知されることもあります(vendor-sec(訳注:vendor-secは、セキュリティを扱う一般公開されていないメーリングリスト)からだったり、 開発元の開発者や監査役から直接連絡を受けたりします)。 そして、セキュリティバグは次のように修正されていきます。開発元の段階(ここでは、わたしたちは、開発元のメンテナからの修正を待ちます)、 ebuildの段階(ここで、わたしたちはパッケージのメンテナに声をかけ、ebuildを修正するよう依頼します)、 安定化の段階(ここでは、わたしたちはセキュリティがサポートされるすべてのアーキテクチャでテストとその修正されたパッケージが安定化させることを要求します)、 そして、最後に、glsaの段階(ここで、必要に応じてGLSAを発行します)。 ときどき、わたしたちはこれらの段階の途中で行き詰ってしまい、わたしたち自身でなんとか解決しなければならないことがあります。 ときどき、解決方法を見つけられず、修正なしではPortageツリー内にセキュリティリスクが残ってしまうため、パッケージをマスクすることもあります。 セキュリティバグの取り扱いは、大部分が適切な人に適切な時に連絡し、 常に事態が改善するように努めることです。 この仕事は、GLSAコーディネータによって実施されるのであって、自動では行われません。 わたしたちは、修正とテストを行うことに関して、他のGentoo開発者たち(パッケージメンテナと各アーキテクチャのチーム)を非常に信頼しています。 セキュリティ上の欠陥はどうやって発見するのですか？ メーリングリスト？警告が来る？自分たちでテストしているのですか？ わたしたちは、基本的にはユーザにできるだけ多くの一般的な脆弱性を提供してもらうことにしています。 セキュリティチームは、気づかれない状態になっているこれらのすべてを理解するように努めています。 セキュリティ上の欠陥は、BugTraq、Full-Disclosure、開発元や他のディストリビューションのセキュリティ勧告のような一般公開されたメーリングリストから来ます。 わたしたちは、ますます一般的なLinuxセキュリティコミュニティの一部として受け入れられてきており、 それゆえ、一般公開されるまえに脆弱性について通知されることもあります。 Gentooから他のディストリビューションなどに対しても貢献するために、わたしたちは最近、セキュリティ監査(Security Audit)のサブプロジェクトを立ち上げました。 わたしたち自身で脆弱性を発見し、わたしたちのパッケージメンテナが彼らのテストによって多くの脆弱性を発見できるようにするためです。 欠陥はいつ判明し、どのように文章化されるのですか？ 大部分は、一般公開されているセキュリティ勧告の情報を単純にコピーするだけです。 そして、Gentoo Linuxにも当てはまるか検証し、その重要度を見積もります。 この重要度が優先度となり、脆弱性の取り扱いポリシー(Vulnerability Treatment Policy)に示されている遅延を考慮します。 欠陥の解決を誰かに割り当てるときに、決まりきった手順はありますか？ どうやって優先度をつけるのでしょうか？どのように修正を文章化し、テストするのですか？ 各GLSAのコーディネータがバグについて判断し、常に確実にそのバグについて事をうまく運ぶように責任を負っています。 もし、バグの解決に行き詰ったら、これを解消するためにすべてのセキュリティ開発者が口を挟むことができるようになっています。 優先度は、重要度によって決まります。後述するようなルールが脆弱性の取り扱いポリシー(Vulnerability Treatment Policy)で述べられています。 もし修正が入手できるようになったら、どのように文章化されるのでしょうか？ 誰がGLSAを書くのですか？GLSAの発信についてはどのように行いますか？どうやって保管するのでしょうか？ わたしたちは、修正をGLSAドラフトに記述します。これは、リリースされる前に少なくとも2人の専門家による肯定的な評価が必要です。 わたしたちは、GLSAMakerと呼ばれるツールを使用していて、すべてのGLSAの一貫性を確保するのに役立てています。 GLSAは、GLSAコーディネータやその見習い(研修中のGLSAコーディネータ)によって書かれます。 GLSAは、gentoo-announceと他のセキュリティメーリングリストに送信され、 すぐに自動的にRDF フィードとGentoo セキュリティページに現れます。 最後に、フォーラムのモデレータにフォーラムアナウンスとして掲載されたもののコピーを入手します。 GLSA XMLソースは、Portageツリーの一部(metadata/glsa内にある)であり、 すべてのユーザの装置と同期しています。 これは、(しばらくの間はまだ試験的ですが)glsa-checkツール(gentoolkitパッケージに含まれます)を使用可能にするためです。 GLSAの元となるユーザは誰でしょうか？Gentooユーザ以外にも警告がでる他の組織があるのでしょうか？ わたしたちは、linuxsecurity.comに対して警告をだしますので、 GLSAは、セキュリティ勧告ページに掲載されます。 MITRE CVE辞書にもGLSAへの参照が含まれます。 チームで作業を管理するために使用している自動化されたツールやスクリプトはありますか？ GLSAMakerを使用しています。これは、Tim Yamin (plasmaroo)によって書かれたGLSA XMLソースコードと本文に相当する部分を書くのに役立ちます。 Portageを使用してセキュリティ問題を特定し、修正するための"emerge security"の状況はどうでしょうか？ "Emerge security"の機能については、gentoolkitパッケージに含まれる"glsa-check"ツールを使用して現在テスト中です。 これは、どのGLSAがあなたのシステムに影響するかを特定し、 自動的に脆弱性のあるパッケージを修正します。 これが準備できたら、Portageツールチームは、emergeのような本流のツールにこれを統合する予定です。 最新のglsa-checkを使用することをお勧めします。そして、おかしいところがあれば、どんなことでも bugzillaを使って報告してください。 ユーザは、セキュリティチームについての情報はどこで入手できますか? わたしたちの主なページは、Gentooセキュリティのトップページであるsecurity.gentoo.orgにあります。 ここには、わたしたちのポリシードキュメントへのすべてのポインタ、最新のGLSAとたくさんの役に立つ情報が含まれます。 Gentooセキュリティプロジェクトに参加したい人は、SecurityプロジェクトWEBページ を読むべきで、特にGLSA コーディネータガイドとセキュリティ・パダワン・ページは、 わたしたちが何を必要としているかを感じ取るために呼んでください(訳注:パダワン(padawan)は、映画スターウォーズに出てくるジェダイの弟子のこと。ここでは単に見習いという意味で使用されている)。 セキュリティチームが最近取り組んでいる、主体的に行っていることはなんですか？ 昨年、すべての明文化されていないチームが従っているルールについては、ポリシードキュメントを参照するようにしました。 いつでも一貫したセキュリティ監視を確実に続けるための新しいチーム(訳注:セキュリティ監査(Security Audit)サブプロジェクトのこと)と一緒に作業するようになりました。 他に知っておくべきことで、わたしたちがまだ質問していないことはありますか? おそらく、それは、管理体制でしょう。Kurt Lieber (klieber)は、わたしたちの戦略的なマネージャで、 Sune Kloppenborg Jeppesen (jaervosz)と私自身は、運営上のマネージャです。 Open-Xchange（OX）とは、NovellのSuSE Linux Openexchange Server（SLOX）を基にしたオープンソースのグループウェアサーバです。Open-XchangeはGNU Public Licenseでリリースされた2004年8月30日からクローズドソースになりました。OXは、現在のプロジェクト（SMTP、IMAP、LDAP、Apache、Tomcat、そしてPostgreSQL）を統合し、強力なメッセージの伝達と共同環境を提供する人気のあるオープンソースサーバテクノロジーに影響を与えます。重要な機能には、メール、プロジェクト管理、バージョンによるドキュメントの保管、カレンダーの共有、そして知識ベースが含まれます。それにはEvolutionやthe Mozilla suite(ThunderbirdとSunbird)といったWebインタフェースやfatクライアントを通すか、WebDAVをサポートするその他のサードパーティーアプリケーションからアクセスすることができます。現在、Open-Xchangeは2005年3月のstableリリース（v0.8）予定に向けて開発中です。あなたが、いくらかひるんでしまうインストールに取りかかる前にOXがどういったものか見たいなら、オンラインデモを試してみることができます。 インストールとサポート Gentoo LinuxにOXをインストールするには現在2つの方法があります。1つはBugzillaのebuild（現在Portageツリーにはありません）を使用することで、もう1つは手動でインストールすることです。Wikiページでebuildを使用したインストールを説明していますが、OXを思い通りに実行させるほとんどの必要な段階は、追加の手動インストールガイドが、Open-Xchangeを拡張するのと同様に必須の構成をカバーしています。Gentoo特有の質問のために、Gentooフォーラムのスレッドにはほとんどの回答である数百の投稿があります。 まだOXが使用するサーバに詳しくないなら、急な学習曲線や多くの読書をするようにしてください。今までのところ経験されている問題の大部分がLDAP構成、Apache/Tomcatの統合、およびSASL認証にかかわります。OXが依存するサーバのすべてが、実際にOpen-Xchangeをインストールする前に、適切に構成されていて動作している必要があります。
OpenMotifにインクルードされているlibXpmに複数の脆弱性が発見されています。これらの脆弱性はリモートからのコードの実行を招くおそれがあります。(注意： これは昨年11月にxorg-x11でfixされた脆弱性と同じものです) 詳細についてはGLSA Announcementを参照して下さい。 ローカルのアタッカーが、PostgreSQLサーバを騙して任意のコードを実行することが可能です。 詳細についてはGLSA Announcementを参照して下さい。 Python： SimpleXMLRPCServerを使った任意のコードの実行 PythonベースのXML-RPCサーバには、リモートから任意のコードを実行されるおそれのある脆弱性が存在します。 詳細についてはGLSA Announcementを参照して下さい。 pdftohtml： インクルードされているXpdfに脆弱性 pdftohtmlはPDFファイルを扱うことを目的として脆弱なXpdfのコードをインクルードしているため、悪意あるPDFファイルの変換中に任意のコードを実行させられるおそれがあります。 詳細についてはGLSA Announcementを参照して下さい。 Mailmanは入力データを正しくサニタイズできないため、情報の漏洩を招いてしまいます。 詳細についてはGLSA Announcementを参照して下さい。 Webmin： Gentooのバイナリパッケージにおける情報漏れ PortageでビルドされているWebminのバイナリパッケージは、偶然にも、ローカルのrootの暗号化されたパスワードを含むファイルをインクルードしています。 詳細についてはGLSA Announcementを参照して下さい。 ファイルの上書きや昇格した権限を使ったコードの実行を招いてしまう脆弱性がperl-suidラッパーに発見されました。 詳細についてはGLSA Announcementを参照して下さい。 mod_python： パブリッシャーハンドラに関する脆弱性 mod_pythonにはパブリッシャーハンドラに関する脆弱性が存在し、情報漏洩を招いてしまうおそれがあります。 詳細についてはGLSA Announcementを参照して下さい。 「noなんとか」USEフラグはやめましょう Michiel de Bruijne 曰く「(Portage)ツリーには、結構な数のebuildが「noなんとか」USEフラグを使っています。基本的に、USEフラグを無効にすれば、利用できる機能が増えます。たとえば、USEフラグを無効にして依存関係をさらに増やすことができます。ただし、これにはひどい副作用があって...」この議論の中で、こうしたUSEフラグを使うべきではない理由が明らかにされています。 パッケージを自動的にstableにしては？ だいたい半年おきに同じ議論が交わされています。「Portageのパッケージを最新の状態に維持するにはどうすればよいでしょうか？単純に考えると、一定期間が過ぎたら自動的にstableにしてしまうという方法でもいいのではないでしょうか？」次のスレッドでは、こうした考えが多くの点で間違っている理由が示されています。 CLOSED？それともRESOLVED？ Marius Mauchの質問です。「最近気が付いたのですが、新しい開発者がバグのステータスを"RESOLVED"から"CLOSED"に変更しているようです。個人的には、こういうのは好きじゃないですし、まったく無駄ではないかと思っています。なんらかの技術的な理由がないのなら、これはやめませんか？特に違いがないのに、クローズされたバグが2種類の「カテゴリ」に分類されても、なにかいいことがあるとは思えません」 米国: オレゴン州立大学LUGでのGentoo Bugdayイベント Gentoo Bugdaysは毎月最初の土曜日に開催されていて、いろいろな場所にいる開発者とユーザがIRC上に集まり、Gentooのbugzillaで対応が必要と思われるものをつぶしていく、というものです。 2月5日に、オレゴン州立大学のLinuxユーザ会(OSLUG)はこの仮想イベントを現実のものにしました。 12人のOSLUGメンバーがオレゴン州立大学の宿泊施設であるWeatherford Hallに集まりました。 この日のためにGentoo Bugday主催者によって事前に準備されたバグリストをもとに、彼らは9時から16時までバグを潰し続けたのです。その間、公式IRCチャネルである#gentoo-bugsがオーバーヘッドスクリーンと教室中に設置されたコンピュータに映し出され、それぞれのコンピュータにはGentooバグ退治担当が張り付きました。
RedHat/SuSE/Mandrake以外で、しっかりとしたサポートがある商用アプリケーションが発表されることはこれまでほとんどありませんでした。 ドイツのSEP AG社は、この度彼らの記憶域管理製品である"SEP sesam"のGentoo Linux版を発表しました。 「私達はもともとはSuSE Linux向けに仕事をしてきましたが、昨年カールスルーエ市で開催されたLinuxTagにおいてLars Weilerが行ったHP ProliantクラスタへのGentooインストールが印象的だったことから、Gentooは我々のレーダーにかかってきたのです。」と、SEPの企画マネージャであるJohann Krahfuss氏(参照: GWN report 28 June 2004)は語っています。 「ということで、SEP sesamをGentoo Linuxに移植してくれ、と要求するお客さまが現れた時も、私達はそれほど驚かなかったです。」 ドイツの連邦研究機関であるFraunhofer Gesellschaftは、SEP sesamをGentoo Linux環境にインストールするように要求した最初の顧客です。 「インストールしてからこれといって問題も発生していないので、公式リリースの段階に達していると思っています。」とKrahfuss氏は言います。 30日間のテストバージョン(サポートあり)は、同社のWebサイトからダウンロードできます。 SEP sesamはLinux、BSD、Solaris、TRU/64、OpenVMS、WindowsそしてMac OS Xなどの多機種混在環境でのデータ蓄積管理をするように作られています。 SEP AG社は来週Nuessで開催されるCRN Storage Solution Days 2005(リンク先はドイツ語のみ)に出展する予定です。 Newsforgeは、Tony Bourkeによって解析し、書かれたusing MySQL to benchmark OS performance(訳注:OSの性能評価するためにMySQLを使用する)という記事について二部構成の記事で公表しています。性能チェックは、MySQLデータベースを実行するプラットフォームとして、サーバ用OSのOpenBSD、NetBSD、FreeBSD、Solaris 10、Linuxで計測を行います。そしてたくさんのディストリビューションがある中で、Linuxプラットフォームのテストに、Gentooが選ばれました。その理由は、ReiserFS上で2.4と2.6カーネル(gentoo-sources)の両方が実行できるからです。「2.6カーネル向けのテストではNPTLを使いますが、Gentooでは2.6カーネルへのNPTLのインストールが比較的簡単だからです。しかし、結果としてNPTLを利用しない2.6カーネルと比較したときに、大きな性能差はありませんでした。」とTony Bourkeは言っています。第1部は、使用するツールとその方法を説明しています。実際の性能比較は、別の記事で書かれています。驚いたことに、Gentoo Linuxは個々のベンチマークテスト全部で、明らかな勝利を収めています。面白いことに、Gentooの突出した性能は、まさにちょうど"unfair advantage"(訳注:不公平な利点)という不平不満を引き起こしました。ソースペースで、プロセッサに合わせた最適化が可能なLinuxディストリビューションを使用するという、比較対象のプラットフォームとしては、"unfair advantage"(訳注:不公平な利点)といえます。 先週のCNETのWebサイト上で公表されたインタビューにおいてGentooのOpenSolarisへの貢献をSUNの取締役のJonathan Schwartzは賛成しています。OpenSolarisの管理モデルについて、インタビュアーのStephen Shanklandに説明している中で、"Solaris is now officially platform-neutral"(訳注:Solarisは公式にマルチプラットフォーム対応になるでしょう)と公言し、これからマーケットに、10種類以上のSUN以外から提供されるOpenSolarisのディストリビューションが登場してくるでしょう。 コラムニストのJason Millerは、「Linuxカーネルの脆弱性問題が適切に扱われていません。今すぐにも修正しなければないといけません。」と語っています。セキュリティのプロフェッショナルによって主に読まれているsecurityfocus.comの記事は、Linuxカーネルにおける、セキュリティバグに関してとても批判的です。しかし、「BSDベースのOSの熱烈な信奉者」を自称する著者は、いくつかの良いニュースも提供しています。「以前、完璧なOSとして当時のLinuxカーネルのディストリビューションを探し始めたとき、主要なBSDベースOSによって提供されるのとよく似たセキュリティ関連ページと同様な、公式なセキュリティ窓口をもついくつかのディストリビューションを見つけました。Gentoo Linuxのセキュリティへの取り組むは、そのようなディストリビューションの中では良い例です。 Reseaux & Telecoms (2005年2月3日 フランス) Jason MillerによってSecurity Focusのコラムを直接受けて、フランスのネットワークと通信マガジンは、カーネルに潜むセキュリティ問題を調査しています。この問題とは、カーネルに依存しない個々のアプリケーションの脆弱性とディストリビューションのセキュリティに関連する情報が、"オープンソースのバグハンター"にとって、どちらも同じように取り組みの重要項目として扱われています。"Noyau Linux : Mais ou est la securite ?"の記事は、Millerの"物事は変わり、早く、正しい方向へ(訳注:向かうべきだ)"という結論を認めて、そして「象徴的な働き」の例としてThierry Carrez(上記、インタビューを参照してください)が称賛しています。現在の、脆弱性情報の取り扱いと情報開示の仕組みを巡る議論を見る限り、「楽観できるだろう」と著者のMarc Olanieは語り、「Microsoft社は18年かけてセキュリティ情報の標準化を行った"はずだ"」と指摘しています。 SUNのエンジニアであるEric Boutilierは、OpenSolarisにおいてGentoo開発者と密に連携をしています。そしてSUNのWebサイト上にある彼のブログに、LinuxのPortageに習熟しようとする彼の初の試みが掲載されています。インストール対象に選んだPCが一風変わっており、通常のインストールよりも楽なGentooクローンのVidalinuxを選び、そして5年前の（東芝製）Portageラップトップ上で、長いコンパイルにもめげず、たちまち普通のPortageユーザに仲間入りしたようです。曰く「まぁ、いいや。コンパイルはほっといて、出勤することにしました。」 Gentooコミュニティでは、バグやお知らせ、提案やその他開発チームとのやり取りの記録、追跡にBugzilla(bugs.gentoo.org)を使っています。2005年2月6日から2005年2月13日までのデータは以下のような結果になっています。
現在オープンしているバグ 8036個のうち、102個が「極めて重大(Blocker)」、243個が「重大(Critical)」、600個が「中(Major)」とラベル付けされています。 本期間内にもっとも多くバグをクローズした開発者、チームは以下の通りです。
本期間内にもっとも多く新しいバグを割り当てられた開発者、チームは以下の通りです。
Portageマジック： obsoleteなpackagesを特定する Gentoo開発者のBrian Harringは、マージされているすべてのパッケージのバージョンの中でPortage内でもう無効になってしまっているものを識別するための巧みな方法をデザインしました -- オフィシャルツリーとPORTDIR_OVERLAYからのパッケージの両方に対して有効な方法です。これが彼の提案する方法です。一行で収まるようなすっきりしたPythonスクリプトにまとめられています：
ちょっと難しいですか？では何をしているのか正確に見ていきましょう。例えばあるパッケージが、そうですね…、foo-1.2.3がマージされていてそのバージョン1.2.3はもうツリー上無効になっているとして、スクリプトはそのことを指摘しているのです。バージョンにかかわらず、もう今後有効ではないパッケージをチェックする簡単な方法はこのような感じになります：
最後に、もしfoo-1.2.3が今後ツリー上に存在せずリビジョンfoo-1.2.3-r1が残っていてもこのパッケージを無視したいのなら、以下のスクリプトが、インストールされたアプリケーションがPortageから完全に消滅したことを契機としてパッケージを無視してくれます。
終わりに、上記はいづれも有効なツリーからインストールされたものだけを対象としていて、インジェクトされたパッケージは考えに入っていません。さて、これらも無視するようにしたいと思いますが、そのためには以下のようにします：
そうです、あなたがやりたかったのはこれですね。上でやったことはオーバーレイツリー、例えば、正規のPortageツリーに含まれているパッケージに加えて一緒に評価される、/usr/local/portageにあなたが保持している個々のパッケージに対して有効に働きます。試してみて下さい。何も壊したりはしません。何が見付かったのかを報告してくれるだけですから。この情報をもとに何をするかは、ユーザに任されています。 最近Gentooチームから次の開発者が去りました。
最近Gentoo Linuxチームに次の開発者が入りました。
最近次の開発者はGentoo Linuxプロジェクトでの役割が変更となりました
Gentoo Weekly Newsletterに参加したいと思った方はメールください。 ご意見、ご感想はこちらへお送りください。あなたのメールがGWNをさらによくする手助けとなります。 Gentoo Weekly Newsletterを購読するには、gentoo-gwn-subscribe@gentoo.org宛に本文・件名に何も書かないでメールを送ってください。 Gentoo Weekly Newsletterの購読を解除するには、本文・件名に何も書かないでgentoo-gwn-unsubscribe@gentoo.org宛てにメールを送ってください。 Gentoo Weekly Newsletterは以下の言語でも読むことができます |
|
