MATSUMOTO Ryosuke
matsu****@gmail*****
2011年 5月 31日 (火) 18:26:38 JST
海外さん 松本です。 非常に分かりやすく、詳細な説明をして頂きありがとうございます。 プロセスが稼動している状態では、Pビットの範囲内でEビットの操作が 可能であることが理解できました。 例えばPビットの範囲内に、 CAP_SETUID CAP_SETGID が含まれていたとすると、とあるルーチン内部で上記CapabilityをEビット にSETしてsetuid、setgidを実行後、とあるルーチン内の処理の最後で、 EビットをCLEARすることで、必要最低限のルーチン部のみにCapability を与え安全にプロセスを再利用する実装が可能と思われます。 このようなプロセスを再利用している状況で、プロセスがのっとられたとす ると、PビットのCapabilityを利用してsetuidやsetgidを実行されることは 可能でしょうか？ PS メールヘッダに引っかかっていた件もありがとうございました。 2011年5月31日17:21 Kohei KaiGai <kaiga****@kaiga*****>: > 海外です > > Linux Capability には 4 種類のビットがあり、それぞれ役割が異なります。 > P : Permitted、E : Effective、I : Inherited および B : Bounding です。 > > このうち、プロセスが Capability を必要とする操作を OS に対して要求した際に > 評価されるのは E ビットですが、残りのビットも E ビットを導出する過程で利用 > されます。 > > セキュアOS塾の資料では言及していませんが、capset(2) システムコールを > 使ってプロセスの Capability を操作する際には以下のような制限事項があり > ます。 > > new P ⊆ old P > new E ⊆ new P > > したがって、実際に Capability として意味ある働きをするのは E ビットですが、 > P ビットの範囲内であれば再設定する事は可能です。 > > もう少し叙述的に各ビットの意味を記すとすれば、 > P ビット…そのプロセスで設定する事が可能な Capability の範囲 > E ビット…特権が評価される時に利用される Capability で、常に E ⊆ P > > つまり、Pビットを放棄すれば、そのプロセスでは二度とその Capability を > 使う事はできませんが、Eビットを一時的に放棄して、特定のルーチンの > 実行時に Capability を使えなくする、という使い分けはできるようになって > います。（禁止されてはいません） > > なお、Pビットは execve(2) の計算時に rootユーザであってもB ビットに > よって制限されますが、Bビットは常に縮退する一方です。 > 確かこれは、chroot(2)を使ってプロセス固有の namespace から脱出 > できないようにして、Solaris Container のような環境を実現するという > 開発目的があったはずです。 > > 2011年5月31日0:50 MATSUMOTO Ryosuke <matsu****@gmail*****>: >> 忠鉢様 >> Capabilityの仕様と概要の情報ありがとうございます。 >> 今回のメールの意図は、Capabilityに関してもう少し踏み込んだ内容に関して >> だと思っていただくといいかと思います。 >>> >>> Linuxにおけるcapabilityの基本的な考え方は，rootが起動したプログラムを，最低限のcapabilityのみを許して実行させよう，という話だと思います． >> 意図としては、Capabilityをセットする際、セットしたいCapability ＊以外＊ のCapabilityを >> 落としすことでCapability機能を実現しています。 >> その ＊落とした＊ Capabilityを再度同じプロセスにセットし直せない様な仕様になっている >> のは、どういうリスクを想定しているのかをお聞きしたいと思っています。 >> もう少し踏み込みます。 >> 例えば、あるプロセスにあるCapabilityのみをセットした状態にし、それ以外のCapabilityは >> 落とした状態だとします。「プロセスにセットしてあるCapabilityを一旦落とした後、再度、直 >> 前までセットしていたCapability ＊のみ＊ をセットし直すことは可能だ」、という仕様を許可 >> することは、リスク的にどういったものが考えられるでしょうか？ >> 2011年5月31日6:03 Shintaro Fujiwara <shint****@gmail*****>: >>> >>> こんにちは、藤原です。 >>> >>> secureos.jp が出てこないんですけど。。 >>> >>> >>> 2011年5月30日22:28 Yosuke Chubachi <piano****@gmail*****>: >>> > 忠鉢（@yuzuhara）です． >>> > >>> >> そこで、このような一方向でCapabilityを抜いていく仕様となった原因やリスクとは具 >>> >> 体的にどういった内容を想定されての仕様なのでしょうか？ >>> > >>> > Linuxにおけるcapabilityの基本的な考え方は，rootが起動したプログラムを，最低限のcapabilityのみを許して実行させよう，という話だと思います． >>> > 参考）海外さんの発表in セキュアOS塾 >>> > >>> > http://www.secureos.jp/index.php?plugin=attach&refer=events%2Fjsosjk02&openfile=20090202-sosjk02-kaigai.pdf >>> > >>> > >>> > ざっくり言えば，原因は「本来，特権の一部が必要なプログラムなはずなのに，すべての特権を許可して（つまりrootで）実行していた」になり，リスクは「プログラムを乗っ取る攻撃により，（結果的に）root特権が奪取される可能性」といえると思います． >>> > >>> > linuxのケーパビリティとはどういうもの？という話は，この辺を読むと良いかもしれません． >>> > >>> > http://www.symantec.com/connect/articles/introduction-linux-capabilities-and-acls >>> > >>> > 以上です． >>> > 2011年5月30日17:18 MATSUMOTO Ryosuke <matsu****@gmail*****>: >>> >> 日本セキュアOSユーザ会の皆様 >>> >> はじめまして、松本亮介と申します。 >>> >> >>> >> Capabilityの設計思想に関してお聞きしたいのですが、Capabilityは権限を落とす方向 >>> >> にしか動作しないようになっていると思います。 >>> >> 例えば、とあるプロセスにsetuidのみのCapabilityがセットされた上体で、一旦setuid >>> >> のCapabilityを落とすと、再度setuidのCapabilityを与えられないような仕様になってい >>> >> ると理解しています。 >>> >> そこで、このような一方向でCapabilityを抜いていく仕様となった原因やリスクとは具 >>> >> 体的にどういった内容を想定されての仕様なのでしょうか？ >>> >> ご存知の方がいらっしゃいましたら、ご教授下さい。 >>> >> ----- >>> >> MATSUMOTO Ryosuke < matsu1229 gmail.com > >>> >> _______________________________________________ >>> >> Japan secure operating system users group >>> >> users****@secur***** >>> >> http://lists.sourceforge.jp/mailman/listinfo/jsosug-users >>> >> >>> >> >>> > >>> > >>> > >>> > -- >>> > 忠鉢 洋輔 >>> > Mail:piano****@gmail***** >>> > >>> > _______________________________________________ >>> > Japan secure operating system users group >>> > users****@secur***** >>> > http://lists.sourceforge.jp/mailman/listinfo/jsosug-users >>> > >>> >>> >>> >>> -- >>> http://intrajp.no-ip.com/ Home Page >>> >>> _______________________________________________ >>> Japan secure operating system users group >>> users****@secur***** >>> http://lists.sourceforge.jp/mailman/listinfo/jsosug-users >> >> >> _______________________________________________ >> Japan secure operating system users group >> users****@secur***** >> http://lists.sourceforge.jp/mailman/listinfo/jsosug-users >> >> > > > > -- > KaiGai Kohei <kaiga****@kaiga*****> > _______________________________________________ > Japan secure operating system users group > users****@secur***** > http://lists.sourceforge.jp/mailman/listinfo/jsosug-users > -- MATSUMOTO Ryosuke < matsu****@gmail***** > http://blog.matsumoto-r.jp/
