HOME情報セキュリティ資料・報告書・出版物調査・研究報告書情報セキュリティ技術動向調査(2008 年上期)

本文を印刷する

情報セキュリティ

情報セキュリティ技術動向調査(2008 年上期)

5 Linux 用の新しいセキュアOS:SMACK

面 和毅

  2008年4月17日に、Linux の新しいカーネル2.6.25 が登場した。2.6.25からは、SELinuxの他に、新たなセキュアOS としてSMACK(Simplified Mandatory Access Control Kernel)が追加された。これは、昨年から続いていた、Linux におけるセキュアOS 実装の論議に対して、カーネルメンテナー側が出したひとつの回答となっている。

Linux におけるセキュアOS 実装の議論(2007 年末)

  Linux 上では種々のセキュアOS が2.4 カーネルの時代から実装されて来た。2.6 カーネルでLinux のカーネル内にセキュリティ実装を盛り込むことが決まったが、SELinux や AppArmor(当時はSubdomain と呼ばれていた)など、どれか一つのセキュリティ実装に縛 られることを嫌ったLinus が、LSM(Linux Security Module)と呼ばれる共通のプラグイ ンを提案し、全てのセキュアOS はLSM 対応させた実装を行うようになった。このLSM に対応して、2003 年にいち早くカーネルツリーにマージされた物がSELinux である。
  その後、2006 年までSELinux 以外のセキュアOS は提案されず、2006 年にLSM を廃 止するべきではないかと言う議論がLKML(Linux KernelMailing List)で行われた。この 提案がきっかけとなり、AppArmor がLKML に提出された。また、その他のセキュアOS 実装(SMACK、TOMOYO Linux など)もほぼ同時に提出された。
  以降、SELinux とAppArmor によるセキュアOS の大議論が展開されて行く。双方と も異なるセキュリティ理論の実装となっているが、特にベースとなるidentifier が、 SELinux では個々にラベルを貼って行く形となっているがAppArmor ではファイルへの パス名をidentifier としているという点から、両者の議論は単なる理論のディベートから、 互いの中傷合戦にまで発展した。また、SMACK に関しては、「SELinux のポリシの書き 方でSMACK と同様の動作をさせられるので、SMACK は不要なのではないか」という意 見まで出され、再度「現状ではSELinux しかLSM を使っていないので、LSM を廃止で きるのではないか」という意見が出された。
  この議論に終止符をつけたのが、LKML に出されたLinus のメールである。このメール では、「You security people are insane. I'm tired of this "only my version is correct" crap.」と言われており、LSM を残し、AppArmor やSMACK のマージをしてこの種類の 議論の終結にしたいとの発言がなされた。
  ここまでが、2007 年末までのセキュアOS に関する大議論の要約である。

SMACK の説明

  SMACKはSELinux と同じくidentifier としてラベルを用いたセキュリティの実装にな っている。SMACK では、プロセス、ファイル、SVIPC などにラベルを付けて行く。ファ イルに関しては、そのファイルを生成したプロセスと同じラベルが付けられて行く。
これらのラベルに対して、SMACK では23 文字までの名前を付けることができる。
また、次の4 つの特別なラベルがある。

    "*" - "star"
    "_" - "floor"
    "^" - "hat"
    "?" - "huh"
	
   アクセスルールとしては、下記のルールが強制される。 (1) "*"ラベルが付けられているタスクからの要求に対しては、全てDENY となる。 (2) "^"のラベルが付けられているタスクからの読み込み/実行要求は、許可される。 (3) "_"のラベルが付けられているオブジェクトにたいする読み込み/実行要求は、許可される。 (4) "*"のラベルが付けられているオブジェクトに対しては、全ての操作が許可される。 (5) タスクとオブジェクトのラベルが一致する場合には、全ての操作が許可される。 (6) ロードされたポリシにより明示的に定義されている操作は、全て許可される。 (7) その他のアクセスは全て拒否される。   /smack/load にsubject, object, access に関して明示的にルールファイルを書き込んで行く。このSMACK の面白い所は、BLP(Bell&LaPadula)モデルやBiba モデルなどをルールファイルによって簡単に設定できる所にある。例えば、

      C(confidential)      Unclass rx
      S(secret)            C       rx
      S                    Unclass rx
      TS(TopSecret)        S       rx
      TS                   C       rx
      TS                   Unclass rx


とすれば、TopSecret のプロセスがConfidential のファイルにRead/Execute することが できる。

SMACK のマージと今後のLinux におけるセキュアOS 実装

  一方、AppArmor は再度2008 年6 月3 日にLKML にパッチを提出したが、今度も大 議論を巻起こしている。それは、彼らのアクセス制御に必要となるため、セキュリティ部 分以外にVFS レイヤなどにもパッチをマージさせようとしていることに起因している。
  ここでもSMACK という前例を見ると、SMACK ではセキュリティ部分(カーネルソー スsecurity/以下)以外を変更するようなパッチを出していないため、他の開発者達を刺激 しなかったことがLKML でスムーズに受け入れられた原因となっているようだ。
  このように、SMACK を前例としてそのカーネルへのマージまでのプロセスを見ること で、Linux への新しいセキュアOS の「良い」提案方法が理解できる。
  セキュアOS も、単一のものよりも複数実装があった方が、それぞれでブラッシュアッ プしていく効果が見込まれるため、今後もSMACK に続いてAppArmor や他のセキュア OS が実装されていくことがユーザとしての観点からは望まれる。

以上

目次へ
次へ