2010年12月29日水曜日

TwidgeをUbuntuで使えるようにする。

Ubuntuのレポジトリに入ってるTwidgeはバージョンが、1.0.2で、9月くらいからTwitterの新しい認証方法、OAuthに対応していないため使えない。
で、公式サイトから、OAuth対応の1.0.6のパッケージをダウンロードしたのだが、今度は、twidge update '(ツイート)' の(ツイート)の部分に日本語が(正確に言えば、UTF8のエンコード文字)入ると、文字化けするんで、TwidgeがUTF8に対応してないくさい。
ってことで、ネットから見つけた情報を元にUTF8に対応出来るよう、ソースコードに修正を加えて、ビルドし、インストールすることに。これが大変だった。

まず、Twidgeの公式サイト(http://hackage.haskell.org/package/twidge)から、ソースをダウンロード、解凍。
コンパイル環境ghcをインストール。
sudo aptitude install ghc6 
解凍したディレクトリに移って、ここ(https://gist.github.com/423901)の情報を元に、以下のファイルを次のとおりに編集する。
twidge.cabal
ConfigFile, directory, HSH, regex-posix, utf8-string, binary,
の部分を
ConfigFile, directory, HSH, regex-posix, utf8-string >= 0.3.5, binary,
 に。

twidge.hs
import Codec.Binary.UTF8.String (decodeString, isUTF8Encoded)
を追加。
argv <- getArgs
の部分を
argv <- return . (map decodeHack) =<< getArgs
に。
optionsの直前に、
where
-- until GHC #3309 is fixed
decodeHack s = if isUTF8Encoded s then decodeString s else s
を追加。

ghc --make -o setup Setup.lhs
 ./setup configure
を実行。多分、依存関係でいろいろ足りないとエラーが出るはず。
なので、ここで、aptitudeを使って、適宜インストール。エラーで出たものをaptitude searchで探してやると、libghc6-*-devってのがよく引っかかるので、それを逐一インストールしていく。ただ、依存関係で1つインストールすると、他のも一緒に引っかかるので、./setup configureをやりながら調子をみると良いかと。
ちなみに、私のやった順(たぶん)。
curl 
libghc6-haxml-dev-1.13.3-37cdb
libghc6-hoauth-dev
libghc6-configfile-dev
libghc6-hsh-dev
で、ここまでやると、最後の最後まで、UTF8-string >=0.3.5が残るはず。しかし、UbuntuのレポジトリではUTF8-stringはインストールできない。
なので、ダウンロードしてコンパイル、インストールするしかないっぽい。(これに気づくのに時間がかなりかかった。)
ここ(http://hackage.haskell.org/packages/archive/utf8-string/)から0.3.5以上をダウンロードし(0.3.6が最新だったので、新しいのを入れた)、展開。
runhaskell Setup.lhs configure
runhaskell Setup.lhs build
sudo runhaskell Setup.lhs install 
でビルド、インストール。
ここまできたら、もうゴールは見える。
twidgeのソースのディレクトリに戻り、
 ./setup configure
 ./setup build
ここで、UTF8-stringのバージョンを、twidgeのコンポーネントが、別々に2つ必要としてて、おかしくなるかもよ、とか言われても、無視。
 sudo ./setup install
で、インストール完了!日本語でtwidgeからツイートできる!ああ、疲れた。

2010年12月25日土曜日

AppArmor Technical Documentation - 3 The Apparmor Security Model

When a file is accessed by name with open(2), mkdir(2), etc., the kernel looks up the location of the object associated with the specified pathname in the file system hierarchy. The lookup is relative to the root directory for pathnames starting with a slash, and to the current working directory otherwise. Different processes can have have different working directories as well as different root directories. See path resolution(2) for a detailed discussion of how pathname resolution works.
Either way, the result of the lookup is a pair of (dentry, vfsmount) kernel-internal objects that uniquely identify the location of the file in the file system
hierarchy. The dentry points to the object if the object already exists, and is a placeholder for the object to be created otherwise.
AppArmor uses the (dentry, vfsmount) pair to compute the pathname of the file within a process's filesystem namespace. The resulting pathname contains no relative pathname components (\." or \.."), or symlinks.
AppArmor checks if the current profile contains rules that match this pathname, and if those rules allow the requested access. Accesses that are not explicitly allowed are denied.

(略)
どちらの方法(各プロセスのルートディレクトリから始まるパスネーム、ないしは、作業ディレクトリからのそれ、からファイルをルックアップすること)でも、ルックアップの結果は(dentry,vfsmount)カーネル内部の、ファイルシステム階層内部のファイルの位置を固有に特定する、オブジェクトのペアです。 dentryは、オブジェクトがすでに存在すればそのオブジェクトを指し、さもなくば、生成される予定のオブジェクトのプレースホルダーです。
AppArmorは(dentry,vfsmountの)ペアを用いて、プロセスのファイルシステムのネームスペース内部のファイルのパスネームを特定します。結果として生じるパスネームには、一切の相対パスネームの部分("."ないしは"..")やシンボリックリンクは含まれません。AppArmorは現在のプロファイルが、このパスネームにマッチするルールを含んでいるかどうか、そして、それらのルールが要求されたアクセスを許可しているかどうかをチェックします。明示的に許可されていないアクセスは拒否されます。

2010年12月19日日曜日

AppArmor Technical Documentation - 2 Overview

AppArmor protects systems from insecure or untrusted processes by running them in con nement, still allowing them to share les with other parts of the system, exercising privilege, and communicating with other processes, but with some restrictions. These restrictions are mandatory; they are not bound to identity, group membership, or object ownership. In particular, the restrictions also apply to processes running with superuser privileges. AppArmor achieves this by plugging into the Linux Security Module (LSM) framework. The protections provided are in addition to the kernel's regular access control mechanisms.
The AppArmor kernel module and accompanying user-space tools are available under the GPL license. (The exception is the libapparmor library, available under the LGPL license, which allows change hat(2) to be used by non-GPL binaries.)
At the moment, AppArmor knows about two types of resources: les, and POSIX.1e (draft) capabilities. By controlling access to these resources, AppArmor can effectively prevent con ned processes from accessing les in unwanted ways, from executing binaries which they are not meant to execute, and from exercising privileges such as acting on behalf of another user (which are traditionally restricted to the superuser).
One use case for this kind of protection is a network daemon: even if the daemon is broken into, the additional restrictions imposed by AppArmor will prevent the attacker from attaining additional privileges beyond what the daemon is normally allowed to do. Because AppArmor controls which files a process can access in which ways down to the individual file level, the potential damage is much limited.
There is work going on for teaching AppArmor about additional resources like ulimits, and interprocess and network communication, but at this time, these resource types are not covered. This is less severe than it might initially seem: in order to attack another process from a broken-into process like a network daemon, that other process has to actively listen. The set of actively listening processes is relatively small, and this sort of interprocess communication is a natural security boundary, so listening processes should be validating all their input already. For protection against bugs in the input validation of those processes, they should also be confined by AppArmor though, thus further limiting the potential damage.
AppArmor protection is selective: it only confines processes for which policies (referred to as profiles) have been de ned. All other processes will continue to run unrestricted by AppArmor.
To confine a process, all it takes is to write a pro le for it, take an existing profile, or automatically generate a profile: for the latter, the process can be run in learning or complain mode in which AppArmor allows all accesses, and logs all accesses that are not allowed by the current profile already. This log can then be used to automatically generate a suitable new profile, or refine an existing one. The application does not need to be modified.
An example pro le together with a complete low-level walk-through of AppArmor can be found in Section 4. The apparmor.d(5) manual page contains further details.
AppArmor is not based on labeling or label-based access and transition rules, so it does not stick a label on each each file in the file system (or more generally, on each object). It identifies files by name rather than by label, so if a process is granted read access to /etc/shadow and the system administrator renames /etc/shadow to /etc/shadow.old and replaces it with a copy (that may have an additional user in it, for example), the process will have access to the new /etc/shadow, and not to /etc/shadow.old.

AppArmorはシステムを安全ではない、あるいは、信頼のされないプロセスから守ります。それは、それらのプロセスを一定の制限のもとで走らせることで行われ、システムの他の部分とのファイルの共有や特権の行使、他のプロセスとのコミュニケーションをそれらのプロセスにいくつかの条件を付して認めます。これらの制限は強制的なもので、個人やグループのメンバーシップ、ないしは、オブジェクトの所有者には結びついていません。とりわけ、これらの制限は、スーパーユーザの権限により実行されるプロセスにも適用されます。[訳注:この2文は、AppArmorがスーパーユーザだから制限を緩くする一方、一般ユーザだと制限をきつくなるという働きはせず、どんなユーザでも(その人がどんなユーザグループに属していても、その人が制限対象のオブジェクトの所有者であっても)制限を強制するという意味でしょう。]AppArmorはこれをLinuxセキュリティモデル(LSM)のフレームワークに接続することで達成します。提供される保護はカーネルの一般的なアクセスコントロールのメカニズムに加えて行われます。
(略)
さて、AppArmorは、ファイルとPOSIX.1e(draft)機能との2つのリソースについて関知します。これらのリソースへのアクセスをコントロールすることにより、AppArmorは効果的に制限されたプロセスが喜ばしくない方法によりアクセスしたり、実行する必要のないバイナリを実行したり、他のユーザとしてアクションを行うような特権を行使(これは伝統的にスーパーユーザに制限されています)したりすることを防ぎます。
(略)
AppArmorの保護は選択的です。AppArmorはそのプロセス用にポリシー(プロファイルとして参照される)の定義されたプロセスを制限するのみです。[ポリシーの定義されていない]すべての他のプロセスは、AppArmorにより制限されないまま走り続けます。
あるプロセスを制限するためにAppArmorの行うことの全ては、そのプロセス用にプロファイルを書くこと、あるいは、すでに存在するプロファイルを適用すること、自動的にプロファイルを生成することです。3つのうち最後のために、そのプロセスは、ラーニングモードないしはコンプレインモードで動作し、そのモードでは、AppArmorはすべてのアクセスを許可し、現在のプロファイルですでに許可されていないすべてのアクセスを記録します。そして、このログは新しくふさわしいプロファイルの自動生成や既存のプロファイルの再定義に利用されます。そのアプリケーションは修正する必要はありません。
(略 大意は、例は第4節で説明するし、もっと細かいことをしりたい人は、apparmor.d(5)manページを参照してね。)
AppArmorはラベリングないしはラベルをベースとしたアクセス及びトランザクションルールには基づいていませんので、ファイルシステム上の各々のファイルに(より一般的に言えば、各々のオブジェクトに)ラベルを付すことはしません[よく分からないけど、AppArmorはこれとは違うらしいから、ここではこの程度で妥協]。AppArmorはラベルではなく、名前によりファイルを識別し、〜(略 例が示される。 大意としては、ファイルをリネームして新しいもので置き換えた場合、新しい方にプロファイルが適用される)

AppArmor Technical Documentation - 1 Introduction

In this paper we describe AppArmor from a technical point of view, introduce its concepts, and explain the design decisions taken. This text is intended for people interested in understanding why AppArmor works the way it does. You may be looking for less detailed, low-level, or kernel centric documentation; in that case, please refer to the AppArmor documentation web site [1].
Sections 2 and 3 discuss the AppArmor security model, while Section 4 shows how to use it from a low-level point of view. Please be aware that lots of details are discussed here which the higher-level tools hide from the average user.

この文書では、AppArmorを技術的な観点から示し、そのコンセプトを紹介、採用されているデザインの方向性を説明するものです。この文書はAppArmorがなぜそのように動くのかに関心のある方々に向けて書かれています。より大雑把な、低レベルな、ないしは、カーネル中心の文書を期待される方がいるかもしれません。その場合には、AppArmor関連文書のWebサイト[1]を参照願います。
第2節と第3節では、AppArmorのセキュリティモデルが論じられ、第4節では低レベルの観点からそれをどのように使うかを示します。ここでは細かいことがたくさん論じられ、それは、平均的なユーザーからは高度なレベルのツールが隠しているものであるということを覚えておいてください。

2010年12月1日水曜日

総動員は核を駆逐しうるか?

2010年11月30日〜12月1日にかけての夜にゆえましさん(@yuemashi on Twitter)とのTwitter上での意見交換について、考えをまとめてみます。
ゆえましさんの意見は、
  • 総動員体制・計画の保有は核の攻撃的プレゼンスに対して守備的プレゼンスを国家に提供しうる。
  • 侵攻国に対して総動員で集められた、国民軍(筆者が便宜上、名づけた)により出血・国力の消耗を強いることで、徹底抗戦のアピールができる。
  • 総動員国家(総動員体制・計画を保有する国、筆者の便宜的定義による)に対して核を使用することはそのアンバランスさから、国際社会の非難を浴びるため、核保有国は総動員国家に対して、 核を使用しえない。
  • それゆえ、核を駆逐する可能性がある。

とのことだったと思います。(少なくとも私はここを重視しました。間違ってたらすみません、予めお詫びしておきます>ゆえましさん)

[12/03 追記]
拙文をご覧になったゆえましさんがご自身のお考えをまとめてくださいました。
「現代における国家総動員と「制度核」の可能性 - ゆえましホーム」
http://yuemashi.web.fc2.com/blogs/others/protocol_Nuclear.html
[追記ここまで]


そこで、言葉通りの核兵器を「実際核」、核兵器に相当するような効果を持つものとして、総動員体制・計画を「制度核」と呼称されました。
ここからは私の意見ですが、「制度核」という考えは非常に面白い考えだと思います。しかし、「制度核」に「総動員」が適切かどうかについては疑問を感じざるを得ません。
(基本的に、私は「総動員」に対し、WWIのイメージから、悪い印象しか持ってないというのはご承知いただきたいです。)

  • 徴募兵が現代の複雑化・高度化した戦闘に耐えうるか?
Wikipediaに書いてあるので、参照願えればと思います。
http://ja.wikipedia.org/wiki/徴兵制度#.E5.BE.B4.E5.85.B5.E5.88.B6.E5.BA.A6.E3.81.AE.E7.8F.BE.E7.8A.B6

  • 「出血量」と「耐えられうる出血量」の問題
この問題は、WWIのヴェルダン攻防戦が良い例と考えられます。ヴェルダン攻防戦を計画・実施したドイツ軍の参謀総長・ファルケンハインは塹壕戦を国家単位の攻城戦と考え、西部戦線の陸上での最大の敵・フランス陸軍の大出血を狙って、この作戦を立案しました。ファルケンハインは1:3〜5のキルレシオを平気で想定したという話もありますが、基本的には、制度核で想定されている戦略の攻防を入れ替えると、基本は同じように思います。
ヴェルダン戦だけを考慮する訳にはいきませんが、フランス軍は一応、防衛に成功したものの、損害はドイツ軍より2万ほど多く、その後、多くの師団で反乱・反抗が起きるなど、 まさに「失血死」寸前に至ります。
話は短絡的になりますが、同等の兵器をもって戦った場合、攻守ともに同等の損害=出血が生じる上、耐えられる出血量にも差があるわけです。徴兵人口がドイツに比べて圧倒的に少ないフランスにとって、双方に同等の出血が生じた場合、フランスの国力消耗が割合としては激しいことは明白です。

  • 国力の消耗とは? 
人的資源に豊富で、兵器は他国からの援助を得られる国が総動員国家の敵だった場合はどうなるのでしょうか?私がここで想定してるのは、ベトナム戦争の北ベトナムなのですが、兵器から自前で整えなければならない国家とこのような国家が総動員対決になった場合、後者の国家の方が圧倒的に有利なのではないかと考えます。
(いろいろ書こうと考えていたのですが、今は思い出せませんw)

  • 国内関係・国際関係の不確定性
総動員に際して国内がうまく回るかという問題が生じます。総動員は緻密な計画のもとに、WWIほどとは言わずとも、ある程度の硬直性が存在してしまうのは間違いないはずです。数百万人を一気に移動させるわけですから。すると、少しでも国内で政府が混乱したり、敵の先制攻撃で交通路が遮断あるいは、中央でなくとも地方司令部に被害が出ると動員が遅延もしくは停止してしまう可能性があります。
国際関係に目を向けると、「制度核」が効果的に機能するための1つが、国際社会の核使用国に対する非難と袋叩きがあるだろうという想定だと思います。
しかし、この想定は正しいのでしょうか?私はちょっと、思いつかないので、説得力にかけますが、何かしらのアピール・方策を以てすれば、国際世論の中立化は可能ではないか考えます。国際世論を自らの側に如何に総動員国家が近づけるかという問題ですから、これも国内関係の不確定性に含まれうるものです。
また、日本の場合、総動員の実施に際して海洋国家ゆえの「余裕」がありますが、敵国がブラフをかけて、それに総動員で応ぜねばならない状況が生じた場合、総動員した日本が自滅的に国力を消耗する可能性があるとの私の指摘に対し、ブラフをかけた国家の側が国際的に非難を浴びるとの意見がゆえましさんから得られましたが、やはりこれもやりようでは、「どちらも悪い」という国際世論をブラフをかけた国家が引き出しうるのではないかと思うのです。

  • 海洋国家の場合
アドホックな異論ですが、海洋国家、ここでは日本の場合としますが、その安全保障にとって最重要なのは制海権で、陸海空で安全保障の上で優先順位を定めれば、空>海>陸であることは当然のこととして考えていいように思います。
この前提に立って考えるのであれば、最も力を入れるべきは空軍力(昔で言うところの基地航空隊)であり、ついで、海軍力となりましょう。
しかし、空海軍は常に動員体制なのであって(http://ww1.m78.com/topix/%82%8D%82%8F%82%82%82%89%82%8C%82%89%82%9A%82%81%82%94%82%89%82%8F%82%8E.html (サイト『第1次世界大戦』中「総動員」)下のほう参照)、総動員をかけても兵力量を増やすことがほとんどできないと思います。要するに、総動員で国力を一時的にせよ低下させる可能性を選択するよりかは、平時に巨大な空海軍力を整備する方が、私には、合理的に思えるのです。

以上より、私は「制度核」という概念は非常に面白く、可能性も感じていますが、その「制度核」に「総動員」を据えるのはいささか不合理で時代錯誤的に感じざるを得ません。並存は(フランスのように)あり得ても、「制度核=総動員」が核を駆逐しうるとも思いません。かと言って、オルタナティヴがあるわけではありませんが。

話はそれますが、M.V.クレフェルト氏は『補給戦』のあとがきで、石津氏が記すところによると、「核保有国は最大級の通常戦力の保有国だから、これからは非対称戦争しか起こり得ない」と主張しているとのことです。(記憶が若干曖昧ですが。)



乱文ですが、以上です。基本的に素人の考えた戯言です。反論はお手柔らかにお願いいたします。