[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[b-free: 1703] Re: B-FreeOSセキュリティ関連



From: Yasushi Shoji <yashi@yashi.com>
Subject: [b-free: 1702] Re: B-FreeOSセキュリティ関連
Date: Sun, 05 Jul 1998 04:50:32 -0400

> なんかOSという言葉の定義がしっかりしてないようなのですが‥。
> daemon系のプロセス達は、OSに含まれて話されているのでしょうか?
> それとも、種類によってはOSのうち?

daemonに過剰な権限を与えざるを得ないOSの機構が問題なのでは。
下層(OSなど)が、より上の層に対して権限を
小出しにできるようになっていないと、ダメということでしょう。

> あと、securityについてはtelnetなどのように認証systemを用いてある一定の
> ユーザーに特定のresourceを与える場合と、sendmailなどのdaemon processな
> ど、一般user以上の「力」を持っている物のbugによるものの、2つがごちゃ
> ごちゃになっているのでは?

両方とも、securityの話題だと思いますが。
sendmailというある一定のプロセスに、特定のresourceを与えるか。

> > App Level の Security Hole って、OS が Security をちゃんとやってない
> > からできるんでしょ?もっと直接的な言い方をすれば、Security のないO
> > Sに「App で Security を何とかしちゃおうという無茶な考え」をするから、
> > ちょっとした bug が命取りになる。

セキュリティというのは、効率/利便性と、相反するものだと思います。
セキュリティを重視して、C言語/アセンブラの使用は禁止して、
Java VM 上で動くようにするとかいうのも、
一つの選択ですが、効率は落ちますね。

> > OS の helpなしで security は実現不可能な気がします。

これには、同意。

> sendmailは、設計上rootのeffective user id(UIDだっけ?)を持たなければな
> らなかったので良く踏み台にされてますが、いやなら他のMTAを使えば良いだ
> けのことでは?

sendmailは、必要以上の権限を持っているのが問題なのですよね。
root権限が必要なのは、巨大なsendmailのほんの一部で、
それも、別に対したことをしているわけではないから。

> 仮に、内部systemをいじるprocessにはOSというrankを持っていて、外とお話
> しするようなprocessはdaemonというrankをprocess tableか何かにいれておく。
> で、とくていのsystem callなどは、process_table -> p_rank == OS でなけ
> ればいけないとか?で、deamonとOSな、processがお話しするときは、認証
> systemを入れるとか?(そんなアホな‥)ウ〜ム、考えがまとまらない‥‥‥。

セキュリティを追求するなら、OS内部でも認証機構は必要だと思いますよ。
通信相手のプロセスは、crackerの起動したプロセスかもしれない...

> > に乗っている OS が簡単に crack されるなら、もしかしたら誰かが、盗難
> > バイクと同じに端末を盗んで内部を改変して「Aki の端末」を仕立てている
> > かもしれないわけで、そんな端末の言うことを信用して、重要な情報をやり
> > 取りするのはばかげているわけです。

別のOSが通信相手の時に、相手に一定のセキュリティレベルを
仮定(要求)することは、難しいと思います。
同じの認証システムを使っていれば、「信頼関係」とかいう概念で、
そういうことができるでしょうが、1台やられるとみんな道連れなので、
たいてい、その信頼関係のあたりから狙われてしまいます。

> #認証する必要もなくbugを持ったprocessも走っていない、つまりDOSくらいな
> #んでもできちゃう様なOS(とは呼べないが ^^;)だとしても、accountが0、外
> #用に開いてる口がないならsecurityは完璧なのでは?

accountが0って、それは、組み込み機器か何かですか? :-)

ずっと前にも書いたことを、繰り返すんですが、
セキュリティを必要以上に高めてしまうと、
変な設定をしてしまったときの回復や、OS自体へのパッチ当てや、
ソフトウェアのアップグレードなどなど、が、繁雑になってしまいます。

するとかえって、一般のユーザの人たちは、めんどくさくて
セキュリティホールをなかなか塞がない事態になってしまって、
セキュリティが低下する危険性もあります。

Microsoft がやっているみたいに、IE のサービスパックを
ダウンロードして直ちにアップグレードできるみたいな仕組みは、
トロイの木馬を送り込まれやすいという危険もありますが、
みんなにセキュリティホールを塞がせる効果もあると思います。

セキュリティの問題には、いろいろなトレードオフがあると思います。

塩澤 秀和  shiozawa@mos.ics.keio.ac.jp