Linux カーネルは、プロセスの statck のパーミッションを Executive に設定します。私たちが知っているように、スタックには一般的に命令ではなくデータが含まれています。特に、バッファ オーバーフロー攻撃は通常、悪意のあるコードをスタックに格納し、システムの悪用に成功すると実行します。スタックのパーミッションがエグゼクティブでない場合、攻撃は避けるべきですよね？したがって、私の意見では、スタックの許可をエグゼクティブに設定することは有害です.Linuxがバッファオーバーフロー攻撃のリスクを冒しているにもかかわらず、これを行う本当の目的は何ですか?
質問する
244 次
2 に答える
2
Linux カーネルはNX、CPU 上のビットをサポートしています。サポートは2004年からあります。
一部のディストリビューションには、使用に必要なオプションを有効にしないカーネルがNX付属していますが、これは、これらのオプションを設定すると (具体的には PAE モードを使用して)、特定のハードウェアで OS が起動しないという事実に関係しています。
そのため、ディストリビューションで提供されているデフォルトを使用するのではなく、カーネルを再コンパイルする傾向があります。そうすれば、一般的なケースではなく、自分のハードウェアに最適化されていると確信できます。
于 2013-03-15T03:28:44.747 に答える
-2
Linux は *nix です。すべての *nix は、アセンブラー/マシン コードで記述された初期の OS に基づいており、セキュリティの概念は存在せず、不要でもありました。より多くの人々がコンピューターを使い始めるにつれて、OS は世界中の多くの人々の貢献によって進化し、さらに重要なことに、コンピューターは外界からより多くの情報を得ることができました。
マシン コードは、ハードウェアを変更せずにマシンの動作を変更する方法としてのみ存在します。最近の人々は C を使用します。C の目的は、アセンブリ/マシン コードを他のプロセッサ アーキテクチャに簡単に移植できるようにすることでした。
スタックは、再帰を実装するための単なる手段です。
機械語にも C にもセキュリティの概念はまったくありません。機械語にマップする抽象化を選択するのはユーザー次第です。Cはそれらの1つではありません。数百万行のコードに散在する算術方程式を検証する必要があるため、有用であるのに十分なサイズのコードベース (Linux カーネル + libc など) を検証する人間と時間はありません。時間とコンパイラも同様であり、言語自体も明確に定義されていません。C プログラムのどこかで 1 つの算術エラーが発生すると、そのプログラムのアドレス空間全体が危険にさらされます。SELinux、スタックスマッシング保護、ASLR、App Armor、NX-bit、ガードページなどをいくら使っても、これは解決できません。
あなたの質問は、野蛮な原始的な男性になぜヨガをしないのかを尋ねるようなものです.
スタック上でのコードの実行を無効にしても (最近ではほとんどの OS でサポートされています)、C コードを所有する方法は無限にあります。 . 今、誰かが「それは修正できる、カナリアが必要なだけだ」と言うでしょうが、それは使用されている言語が C であるという事実を修正するものではなく、ここでの本当の問題から人々の注意をそらすだけです。セキュリティが必要な場合は、C. PERIOD を使用できません。
于 2013-03-15T04:09:12.290 に答える