アカウント名:
パスワード:
80386以降にはメモリの仮想化とアクセス保護が例外なく搭載されていて、他のプロセスが所有するメモリには読み書きさせないという機構が十二分に用意されています。
元レスにもあるようにウイルスが蔓延するのは、Windowsそのもののアクセス権限の設定が弱すぎて意味を為していないのと、ユーザが当たり前のように特権を使いすぎているという二つの理由があります。 前者についてはWindows 2000/XPになってかなり改善されたものの、未だに数多く存在する「利用するにあたってAdministrator権限を当たり前のように必要としてしまうソフトウエア」が問題の原因です。 後者についてはPCメーカーのデフォルト設定もあるのでしょうが、*NIXで言うところのrootで最初からログインするよう設定されていたり、一般のユーザでログインしても特権モードに移行するためのUIの用意が足りなすぎたりして「面倒だから全部Administatorにしてしまえ」という安易な考えを生む土壌と化しています。もちろん初心者向けの書籍でこういうアクセス権限に言及しているものが少ないというのもあります。
いずれにしてもユーザが意識的にCPUのメモリ保護機能に由来するアクセス権限を適切に利用し、「適切に使っていなければ一生の恥」と思わせるような環境作りが大事だと思いますです。
セキュリティーホールの多くは実装者/運用者の見落しによって起こります。 複雑なセキュリティモデルはそれだけ見落しが起こりやすくなり、穴も残りやすくなるのではないでしょうか?
Un*xに触れて最初に憶えるのは「ユーザ/グループ/その他」という概念です。 Un*x系OSが成功と言わないまでも生き長らえてきた理由の一つは、その最初に憶えた事が普遍的に通用するというセキュリティモデルの単純明快さにあるのではないかと思います。
セキュリティを極めるにはより複雑な仕組みが必要かもしれませんが、セキ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
BIOSのセキュリティは? (スコア:0)
Re:BIOSのセキュリティは? (スコア:1, すばらしい洞察)
Re:BIOSのセキュリティは? (スコア:0)
#使い勝手がいいものかどうかはわかないけど
いずれにせよ、マクロウィルスの類に対しては無力ですが。。
Re:BIOSのセキュリティは? (スコア:1, 興味深い)
80386以降にはメモリの仮想化とアクセス保護が例外なく搭載されていて、他のプロセスが所有するメモリには読み書きさせないという機構が十二分に用意されています。
元レスにもあるようにウイルスが蔓延するのは、Windowsそのもののアクセス権限の設定が弱すぎて意味を為していないのと、ユーザが当たり前のように特権を使いすぎているという二つの理由があります。
前者についてはWindows 2000/XPになってかなり改善されたものの、未だに数多く存在する「利用するにあたってAdministrator権限を当たり前のように必要としてしまうソフトウエア」が問題の原因です。
後者についてはPCメーカーのデフォルト設定もあるのでしょうが、*NIXで言うところのrootで最初からログインするよう設定されていたり、一般のユーザでログインしても特権モードに移行するためのUIの用意が足りなすぎたりして「面倒だから全部Administatorにしてしまえ」という安易な考えを生む土壌と化しています。もちろん初心者向けの書籍でこういうアクセス権限に言及しているものが少ないというのもあります。
いずれにしてもユーザが意識的にCPUのメモリ保護機能に由来するアクセス権限を適切に利用し、「適切に使っていなければ一生の恥」と思わせるような環境作りが大事だと思いますです。
Re:BIOSのセキュリティは? (スコア:2, 参考になる)
特権の無い任意の人が使えるようになってないと困ることが
まとも(^^;な設計で考えれば判るであろう機能なのに、
なぜか特権を必要とするるように作られていて、それが使いたいがばっかりに
使いたくない機能も抱き合わせで使えてしまう特権階級にならないとならない、
という面が頻繁に有るみたいですね。
ただ、
>ユーザが意識的にCPUのメモリ保護機能に由来するアクセス権限を適切に利用し
CPUもWindowsもそうなんですが、与えられた単一の保護モデルが、凄く使いにくい、ということは有るようです。
例えば、コンポーネントな世界とかJavaOSやSmalltalkOS(藁)とかみたいなことをしようとすると、
境界の壁が高すぎるProcessという仕組みは、邪魔である、とかね。
----
ところで、ちょっと思ったんですが、あれって、
保護の単位をもっと細かくしたらどうなんでしょうか?
かつ、その単位を、単純な上下方向だけじゃなく、もっと多次元化したら、どうなんでしょう?
仕事で使ってる某システムは、ユーザx対象クラスx対象オブジェクトの状態x呼ぶメソッドの組み合わせ
(xは掛け算記号のつもりです)各々に対して、メソッド実行の許可不許可の設定が出来ます。
あれくらい細かくかつ多次元的に設定が出来ると、余計な機能を抱き合わせず
必要な機能(メソッド呼び出し)だけが許されてる組み合わせを、作ることが出来ます。
え?手間がかかる、ですか?
そういうのは、その設定自体をファイルにダンプ/リストアできるようになっていれば、済むんじゃないかな?
つまり設定業者にファイルを作ってもらうとか、環境移行のときにそのファイルをコピーするだけで済むとか、
にすることで手間を劇的に減らせるようにすればいいのであって。
Re:BIOSのセキュリティは? (スコア:0)
一度ご覧になるとよいかと。
単一プロセス内で
複数のアプリケーションが有限のスレッドを使い回しつつも
セキュリティレベルはアプリケーション・ドメインで
分離したりとか、いろいろ
Re:BIOSのセキュリティは? (スコア:0)
セキュリティーホールの多くは実装者/運用者の見落しによって起こります。
複雑なセキュリティモデルはそれだけ見落しが起こりやすくなり、穴も残りやすくなるのではないでしょうか?
Un*xに触れて最初に憶えるのは「ユーザ/グループ/その他」という概念です。
Un*x系OSが成功と言わないまでも生き長らえてきた理由の一つは、その最初に憶えた事が普遍的に通用するというセキュリティモデルの単純明快さにあるのではないかと思います。
セキュリティを極めるにはより複雑な仕組みが必要かもしれませんが、セキ