GNU / Linux用の悪意のあるソフトウェアとその戦い

私はHabréのトピックを読む： «Trojan.Winlockは「学習を通じて普及し始めました 。 原則として、根本的に新しいものは何もありません。もちろん、いつものように、コメントには「そしてlinux / mac / freebsd / plan9にはそんなものはありませんが、Windows SSZBユーザー」というようなメッセージがたくさんあります。 だから、私の考えを共有し、誰が何を考えているのかを見つけ、GNU / Linuxにマルウェアが存在する可能性を見つけ、それに対してどうするかを考えるために、新しいホリバーを始めたいと思います。

問題

GNU / Linuxソフトウェアには、他のOSソフトウェアと同様に脆弱性が含まれており、それについて何もすることはありません。 少し前、私は（私は関係ありません、覚えていない）任意のプレーヤーやコーデックライブラリで見つかった脆弱性についてのニュースに出くわしました。 この脆弱性により、特別に細工されたファイルを処理するときに任意のコードが実行される可能性がありました。 しかし、これまでのところ、Flashを例に取ることができますが、それは重要ではありません。



特別なファイルを開くと、その中に任意のコードが実行される、非常に脆弱なプレーヤーがあるとします。 そのようなコードは何ができますか？ 権利を向上させるカーネル内（またはその他の重要な部品で）いずれかの脆弱性がある場合は、いたずらは、彼が唯一のホームディレクトリ内のでした。 しかし、最も価値があるのはホームディレクトリにあります（はい、バックアップについて覚えています）。 つまり 損傷の可能性/貴重な情報（パスワード、文書など）をマージし、ボットネットのPCユーザーの勇敢な兵士を介してユーザのファイルを削除します。 システムの残りの部分を台無しにし、他のユーザーを傷つけ、深刻なLinLock（簡単に削除できない）を作成することは失敗します。



コードをシステムに残すことはできますか？ / execをnoexecオプションでマウントしますが、攻撃者はスクリプトを使用する機会があります。 悪意のあるコードが〜/ .config / long / path / hard / to / find / zlovred.pyファイルを作成し、その自動実行を.profileファイルに追加するのを止めるものは何もありません。 また、マルウェアを〜/ .config / autostartまたは他の場所に登録することもできます。場所を見つけることができると思います。



つまり たわごと一度ホームディレクトリに、このようなUSBドライブとしてあまりにも頻繁に、可能な限りの起動とたわごとに登録することができます。 フラッシュドライブといえば。 レッツ脆弱性は、プレイヤーで、かつthumbnailer'omのpreveshekビデオを作成する方法を他のものの間で使用されているライブラリ、ではありません。 ユーザーは、すなわち、USBフラッシュドライブを挿入し、システム上で...それはnautilus'om、オウムガイはプレビューを作成するために、ヘルパープロセスを起動するすべてのマルウェアを開きます どこでもクリックする必要はありません。USBフラッシュドライブを挿入しました-ウイルスに感染しました。

私が何かを見逃したか、考慮に入れなかった場合、コメントをお願いします。 上記が失敗した場合、ユーザーがFlashの脆弱性を介して敵のサイトにアクセスすることで幸せな生活を台無しにするのを防ぐにはどうすればよいですか？



はい、Linuxは動物園の分布とウイルス作成者は、アカウントにたくさんのニュアンスを取る必要がありますが、あなたがしたい場合は、その後のことができますがあり、それほど一般的ではありません。 Linuxはあまり人気がありませんが、人気になるとどうなりますか？ ボットネットの所有者は、Linuxの場合、マルウェアを作成するのが少し難しいという事実のために、その数を増やすことを拒否しますか？ そうは思いません

どうする

Linux用のアンチウイルス？ まさか！



すべてのプログラムは最小限の特権で実行する必要があります。 プログラムを実行しているユーザーの特権は冗長です。 はい、それは私のずっと前にすでに発明されていました、私はこれがどのように機能するかについて私の考えを表現したいだけです。



プレーヤーには何が必要ですか（できますか）？ 彼はファイルを読み、〜/ .config / playerに書き込み、必要であればURLを開くだけです。 他のすべては必要ではなく、むしろnizyaaaaa（Poluninの声で）。 フラッシュはさらに小さく、ネットワークと、何らかの種類の〜/ .config / adobe / flash（またはそれはどこにありますか？）です。 おそらく一時ファイル用など、さらにいくつかのディレクトリが必要ですが、これはすべて明らかに制限されています。



それではどうしますか？ 強制アクセス制御ツールはすでに存在します-SELinuxおよびAppArmor。 私のように、それらを変更しても害はありません。 たとえば、AppArmor（私は表面的にはSELinuxに精通しています...たぶんすべてがそこにあるのでしょうか？）、そこに権利をトリミングする必要があるアプリケーションごとに、特別な構成を記述して/etc/apparmor.d/に配置する必要があります。 このアプローチは十分に柔軟ではないように思えます（私が知る限り、SELinuxも柔軟ではありません）。 スーパーユーザーの権限なしに、そのようなプロファイルをその場で作成する十分な機会はありません。 すなわち：

1. アプリケーション自体からアプリケーションセキュリティプロファイルを作成するためのインターフェイス
   
   
2. 指定されたプロファイルでアプリケーションを起動するためのインターフェース
   
   
3. その場で他のアプリケーションのプロファイルを編集するための特権をアプリケーションに割り当てる機能。 既に適用されているプロファイルを変更する
   
   
4. プロファイルテンプレート、実行可能ファイルの形式の変更、パッケージの変更が可能
   
   
   
   

たとえば、同じリーキープレーヤーが起動します。 まず、特別なAPIを介したプレーヤープロセスは、自身に制限的なプロファイルを適用します。 つまり プレーヤーの開発者が明示的に必要なアプリケーションの権限のリストに適切なコードを追加する必要があります。 「すべてのファイルを読むことができます、あなたはその設定に書き込むことができ、それが何かすることはできません。」のようなもの つまり この方法は、アプリケーションにバグが含まれている可能性があり、プログラムの動作からシステムを制限したいことを知っている開発者向けです。 または、適切なコードを配布の一部として追加できます。 はい、コードを編集する必要がありますが、多くの編集はありません。 （AppArmorの中のように）このように、ほかに、この機構は、単一のアプリケーションプロファイル、すなわちを許可する必要があり、権利を削減することは可能であってもよいが、増加しません アプリケーションがハッキングされた場合、何も変更できません。 このような安全性プロファイルは、さらなる作業が不要になったすべてのファイルを読み出し/書き込みできるアプリケーションを使用するために、例えば、始動直後すぐに適用、またはすることができます。

プロファイルをいつ適用するかは、開発者が決定します。



あなたは、問題とクローズドソースのアプリケーションで、たとえば、プロファイルを適用することができますので、必ずしもすべてのアプリケーション。 さらに、起動のコンテキストに応じて、異なるプロファイルを適用する必要がある場合に状況が発生する場合があります。 このために、メカニズム番号2が必要です。 これを使用すると、アプリケーションはプロファイルを使用して別のアプリケーションを起動できます。 私の意見では、最も適切な例はブラウザとプラグインです。 Flash、Javaアプレット、Silverlight、およびその他のプラグインは、起動時に権限を制限するセキュリティプロファイルを取得します。 Flashに3倍の穴を空け、ファイルシステムにアクセスするためのActionScript APIを持たせてください。何もできません。



すべてがうまくいくようです、つまり ほとんどのアプリケーションはこの方法で制限できます。 しかし、いくつかの問題があるかもしれません。 潜在的にファイルの読み取り/書き込みが必要なアプリケーションの処理。

ブラウザには、ダウンロードしたファイルを保存する機能が必要です。 あなたは別のディレクトリ〜/ダウンロードにそれを制限することができますが、それは安全の利便性を犠牲になります。 一部のエディターには、原則として、任意のファイルの読み取りおよび書き込み機能が必要です。 この場合、アイテム番号3が役立ちます。 ファイルを開いて保存するためのダイアログは、別のプロセスに移動する必要があります。たとえば、/ etc / apparmor / trusted_programsでは、/ usr / bin / gtk-open-dialogおよび/ usr / bin / gtk-save-dialogが「オンザフライ」で変更できることを記述します»すでに実行中の他のアプリケーションのプロファイル（たとえば、/ proc / [pid] / aa_profile経由）。 当然、特別なプログラム自体が起動された同じユーザーのアプリケーションプロファイルのみを編集できます（ダイアログを開いたり保存したりする）。

ブラウザが起動し、プロファイルが適用され、すべてが制限されます。 ダウンロードしたファイルを保存する必要がある場合、ブラウザはgtk-save-dialogを起動します（当然、kdeには独自のギズモが必要です）。 ユーザーは、保存するファイル名を明示的に選択します。 Gtk-save-dialogは、ブラウザプロセスのプロファイルに対応する例外を作成し、ファイル名をブラウザに返します。 したがって、アプリケーションは、ユーザーが明示的に許可したファイルのみを読み書きできます。 アプリケーションは、（ただし、ファイルのリストを取得することは十分に安全である、私は思う）ファイルのリストを取得することができなかったというディレクトリそのものを禁止するために読むことができます。 オフィスプログラム（および他の多く）でも同じことができます。 すべてのマクロやその他の安全でないものがワードプロセッサで許可されている場合、おそらくオフィスのドキュメント自体と、その時点で既に開いているドキュメントのみを除いて、何も台無しにすることはできません。 ユーザーにとっては、すべてが同じままで、同じプログラム、同じダイアログ、新しいものは何もなく、不便はありません。 プログラマのために、あまりにも、変更を加えることなく、すべて同じコールダイアログボックスの機能表示を行うことができます。 ウィジェットライブラリ（Gtk、Qtなど）を修正する必要があるだけです。



4番目のポイントが残った。 なぜ必要なのですか？ 未検証のソースからアプリケーションを安全に起動するために必要です。 今では、 GNU / Linuxがより一般的になり、多くのアプリケーションが使用されるようになり、4番目のポイントが必要になります。 原則として、GNU / Linuxでは、信頼できるソースからのアプリケーションはリポジトリですが、未検証のソースからアプリケーションをインストールする必要がある場合があります。 4番目の項目は次のとおりです。システムには、セキュリティプロファイルのテンプレートが含まれています。これらは標準です。 実行可能ファイルにはプロファイル名/ IDが含まれています。 アプリケーションの起動時にプロファイルが適用されます。アプリケーションにid /プロファイル名が含まれていない場合、または潜在的に危険な権限が必要な場合は、ユーザーに警告が表示されます。 したがって、ユーザーは未検証のソースから多数のアプリケーションをダウンロードして実行できます。もちろん、システムアプリケーションはここに属していません。 潜在的に危険な多くの特権が必要になります。 ゲーム、小さなユーティリティ、スクリーンセーバーなど、あらゆる小さなもの。 落ち着いて起動することができ、アプリケーションが特別な権限を必要としない場合は、ユーザーにまったく通知されない可能性があります（「 www.zlovredi.ruからダウンロードしました 。未検証のソースから実行可能ファイルを実行してもよろしいですか？」）すぐに実行します。 なぜテンプレートとプロファイルの名前/ IDだけでなく、セキュリティプロファイルを直接実行可能ファイルにありますか？ そのため、プロファイルをチェックし、そのセキュリティについて結論を出すパーサーが必要になるため、今回は起動時に、さらに、未検証のソースからのセキュリティプロファイルを介したカーネルへの攻撃が除外されます（何も書いたことはありません...カーネルにはDoSがあります） 。 これはすべて、私が知る限り、モバイルデバイスのアプリケーションでの作業に似ています。

なぜこれを書いたのですか？

私は自分の考えを表明したばかりで、GNU / Linuxのセキュリティのトピックについて議論することに興味があります。 もちろん、私は根本的に新しい何かを説明していませんでしたが、ここで説明するいくつかのアイデアは、私は会ったことがない（例えば、対話のオープンの問題を他のプロセスで保存）、多分それは本当に便利なアイデアです。 カーネルのパッチを急いで作成しなかったのに、Habréについてのトピックを書いたのはなぜですか？ 残念ながら、Cについての私の知識、さらにはコアについての知識には、多くの要望が残されています。 さらに、提示されたアイデアを議論し、Ubuntu Brainstormでそれについて書くことも考えられます（このトピックについては2、3の行を書きましたが、英語がまあまあか、それとも誰も必要ありません。リンクを見つけます-ここに追加してください）または同様のリソース。



PSこのトピックを書くのに適したブログを選んだかどうかはわかりません。 彼がここに属していない場合は、私が負担します。



[更新1]

小さな追加1：

私はここで説明するどのような - 既存のAppArmorを補足します。 アプリケーション自体からプロファイルを作成するためのAPIは、現在テキストファイルに存在するAppArmorプロファイルに代わるものではなく、追加されたものです。

いくつかの場合に役立つと思われます：

- 1つの用途は、用途に応じて異なるプロファイルでの作業、すなわちを洗ってます さまざまな方法で自分の権利を削減します。

- 開始直後にはできません背面右側にカットし、少し後。

たとえば、大きな権利を必要とするコードの完全にテストされ、なめられたセクションを作成した場合、アプリケーションは権利を必要とせず、それらはカットされます。

つまり これは、柔軟性を追加するアドオンであり、代替ではありません。



小さな追加2：

権利はいつでも減らすことができます。 パラグラフ3でのみ、禁止事項を許可できます。

特権プログラムと既に実行中の別のプロセスのみが許可できます。

上記について詳しく説明しますので、もう一度お読みください。



小さな追加3：

古典的なAppArmorの場合のように、この権利システムは古典的な権利システムよりも優先度が低くなります。 つまり ユーザー自身にとって何かが不可能な場合、プロファイルに関係なく、すべてのアプリケーションでこれは不可能です。



[更新2]

Mac OS Xが同様のものを開発していることがわかりました。

techjournal.318.com/security/a-brief-introduction-to-mac-os-x-sandbox-technology

developer.apple.com/library/ios/#DOCUMENTATION/Security/Conceptual/Security_Overview/Security_Services/Security_Services.html

リンクのint80hに感謝します。

ところで、私の記事で説明されているように、また「必要ない」というコメントで述べられているように、特別なAPIを介してアプリケーション自体からの権利を制限する機会があります。



興味深いことに、Windowsにはすでに似たようなものがありますか？