アプリがユーザーファイルに完全にアクセスできないようにする

Question

ユーザーが許可しない限り、アプリケーションは他のアプリケーションのデータまたはユーザーのプライベートデータにアクセスできません。これは明らかなニーズではありませんか？しかし、私たちが起動するすべてのプログラムは、$ HOMEディレクトリ、マイク、およびカムへのフルアクセス権を持っています。ほとんどのユーザーは、（たとえば）Skypeが自分のプライベートファイルのどこかに送信を開始したり、マイクからサウンドをストリーミングしたりしても気付かないでしょう。

これを修正する方法を探しています。メソッドがSELinuxポリシー、LSMモジュール、カーネルパッチの記述、別のUNIXのようなOSへの切り替えを示唆している場合でも、自由に提案してください。

ここに私が持っていたいくつかのアイデアと私がそれらを拒否した理由があります：

信頼できないアプリごとに新しいUNIXユーザーを作成します。 SUIDビットを使用して、そのアプリを常にユーザーとして実行します。悪い。信頼できないすべてのアプリと、インストールするすべての新しいアプリをブラックリストに登録する必要があるためです。大量の作業、見落としやすいもの。また、アプリをアップグレード/再インストールすると、バイナリがSUIDフラグを失う可能性があります。さらに、子プロセスにも問題があります。理論的には、権限のないアプリは他のアプリを使用して目標を達成できます。 SUIDを使用しない場合、すべての信頼されていないアプリを起動するために "su"を使用する必要があることを思い出すのは困難です。
私たちはSELinuxドメインの移行を使用して、信頼できないアプリを制限します。また悪い。＃1と同じ問題。信頼できないすべてのアプリに対して、SELinuxポリシーを記述/更新/挿入する必要があります。アプリにフルアクセスではなく、デフォルトで特別なアクセス権を与えないようにしたい。
信頼できるアプリのために、新しい「信頼できる」UNIXユーザーを作成します。グループを使用して、プライベートデータのさまざまなカテゴリ（写真、メモなど）を実装できます。ただし、SUIDを使用することはできず、アプリを起動する前に（パスワードを使用して）そのユーザーに手動で切り替える必要があります。このオプションの問題は子プロセスです。信頼されたプログラムのすべての子プロセスが信頼されることを許可することはできません（信頼されたファイルマネージャーでメディアファイルを開いた場合、メディアプレーヤーがファイルマネージャーの信頼されたステータスを継承しないようにします）。ただし、すべての子プロセスが権限をデフォルトに落とすこともできません。また悪い！
SELinuxを使用して、すべての信頼できるアプリに「信頼できる」ドメインを実装します。この場合、自動ドメイン移行は使用できません。したがって、ドメインをパスワードで切り替える必要があります。このような信頼できるドメインで信頼できないアプリを起動することを禁止できるため、このオプションは＃3より少し優れています。しかし、それでも悪くて不快です。
もっと考えると、実行可能バイナリにアクセス許可をまったくバインドできないことがわかり始めています。たとえば、Pythonインタープリターは、実行するスクリプトに応じて異なる権限が必要になる場合があります。そのため、オプション＃1と＃2を忘れることができます。
独自のLSMモジュール（SELinuxなど）を作成できます。しかし、それはどのように機能するはずですか？アイデアがあるかわかりません。インタラクティブモード？一部のプロセスがプライベートファイルを読み取ろうとするたびにユーザーの許可を求めますか？それとも、「lomac」（低透かし）モデルからいくつかのアイデアを取り入れるべきですか？たとえば、信頼できないデータを読み取ると、環境が汚染され、プライベートデータの読み取りがブロックされます。
ユーザースペースデーモン+ LD_PRELOADライブラリ？この場合、アプリはデフォルトでプライベートファイルにアクセスできませんが、特権デーモンにアクセスして、そのようなファイルを開いてファイル記述子を渡すように要求することができます。これは実行可能であり、Windowsの古い「対話型ファイアウォール」のように見えます。

他のアイデア？既成の解決策を知っていることを教えてください:)

[〜＃〜]更新[〜＃〜]

私は自分のLSM（SELinuxの代替）の開発を始めました。ここには誰も興味がないようです。しかし、念のため、ここで私を見つけることができます。

https://gitlab.com/mogryph/chariot

またはここ：

knight@mail.ua

Sion0 · Accepted Answer

私に合った解決策は見つかりませんでした。それで、結局、自分のLSM（Linux Security Module）の開発を始めました。現在、それは開発の初期段階にありますが、私が望んでいたことを（ほぼ）達成することはすでに可能です。基本的な原則は次のとおりです。

ユーザーは最大64個の権限を定義できます。権限は番号で識別されますが、人間が読めるエイリアスもある場合があります。例：
- 1 = "プライベートな写真を読むためのアクセス許可"
- 2 = "ブラウザのCookieの読み取りおよび書き込み権限"
- 3 = "プライベートノートの読み取りと書き込みの権限"
シンプルなユーティリティを使用して、ユーザーは設定するファイルをマークできます。
a）このファイルを読み取るために必要な権限。
b）このファイルを変更するために必要な権限。
c）このファイルの権限may実行された場合に持つ。
例：
- 特定の写真ファイルを読み取るために必要な許可＃1（priv写真の読み取り）を作成します。
- プログラム "/ bin/firefox"が実行された場合、権限を持たないように設定しました（これがデフォルトであるため意味がありません）。
- プログラム "/ bin/cat"が実行された場合、どのようなパーミッションも持つことができるように設定しました。
- プログラム "/ bin/imageview"は、許可＃1を持つことができるが、他の許可を持つことはできないと設定しました。
[〜＃〜]重要[〜＃〜]プログラム（プロセス）は、親が持っていないアクセス許可を持つことができません。例：
- 「/ bin/firefox」では、「/ bin/cat」を使用してプライベート写真を読み取ることはできません。「cat」は、「firefox」によって起動された場合、すべての権限を失います。
PID 1（すべてのユーザースペースプロセスの親）は、完全な権限で始まります。その後、すべてのプログラムのアクセス許可は、このプログラムが持っていないアクセス許可を親のアクセス許可から削除することによって決定されます。
デフォルトでは、プログラムには権限がありません。また、ファイルを読み取る/変更するための権限は必要ありません。したがって、LSMを有効にしても何も壊れません。
「インターネットの使用」や「マイクの使用」などのシステム権限を実装する計画もあります。

このような何か...そのようなロジックで重大な違反が見られたら教えてください。

私のPCでは、systemd、agetty、login、bash、xinit、sh、startkde、start_kdeinit_wrapper、start_kdeinit、kdeinit5、konsoleのすべての権限を強制的に与えられました。

これで、KDEメニューまたはkonsoleから起動するプログラムmayは、すべての権限を持ちます。しかし、それらのほとんどはもちろんありません。

Steffen Ullrich · Answer

ユーザーが許可しない限り、アプリケーションは他のアプリケーションのデータやユーザーのプライベートデータにアクセスできません。 これは明らかなニーズではありませんか？

いいえ、これは明白ではありません。従来、システムにインストールされたソフトウェアは信頼できると見なされていました。つまり、ユーザーがインターネットにアクセスして有害な可能性のあるアプリケーションをダウンロードすることは想定されていませんでした。また、ユーザーが安全でないソフトウェアを実行して、リモートサイトとのやり取りが悪くなり、リモートの攻撃者がローカルデータにアクセスできるようになることも予想されていませんでした。

したがって、UNIX（およびその他のOS）のセキュリティ境界は、アプリケーションではなくユーザーによるものです。実際、アプリケーションの概念すらありません。複雑なアプリケーション（Officeなど）は、実際にはいくつかのバイナリ、ライブラリ、構成ファイルなどで構成されています。

この設計は、多くの使用例、つまりシステムが最初からあまり変更されない場合や、信頼できるソフトウェアのみがインストールされる場合でも有効だと思います。しかし、現在では、ユーザーが信頼できない可能性のあるソースからソフトウェアを実際にインストールしたり、安全でない可能性のあるソフトウェアをインストールしたりして、このソフトウェアがあまり害を及ぼさないことを期待する場合もあります。これらの場合、ユーザーのみをセキュリティ境界として使用するという元のパラダイムでは不十分です。

異なるパラダイムで設計されたOSがあります。つまり、ユーザーが悪意のある可能性のあるアプリケーションをインターネットからダウンロードし、プライベートデータへのアクセスを制限したい場合が一般的です。たとえば、Androidの例では、各アプリケーションは基本的に独自のユーザーとしてインストールされているため、ユーザー境界を使用して、別のアプリケーションによって生成されたデータへのアクセスを制限します（これは動作が少し簡略化されています）。

したがって、デフォルトで信頼されていないアプリケーションを検討する場合は、別のパラダイムで設計されたOSを変更するのではなく、このパラダイムを中心に設計されたOSを最初から実行する方がよいでしょう。ご存じのとおり、信頼されていないアプリケーションの概念を、信頼されたアプリケーションを中心に設計されたシステムに適用しようとすると、扱いにくく不便です。

CBHacking · Answer

SELinuxの代わりに AppArmor を参照することをお勧めします。それはあなたが望む振る舞いを提供し、維持するのがより簡単です。ただし、実行したいallプログラムに適したAppArmorプロファイルを定義するのは大変な作業なので、通常は、信頼できない、またはセキュリティの低いプログラム（開発者/発行者がプロファイルを提供していない場合）。

つまり、汎用オペレーティングシステムは、概して、この種のサンドボックス化向けに設計されていません。サンドボックス化は近年、OS機能としてますます人気が高まっていますが、期待どおりに普遍的に実装されていないのには理由があります。簡単に言うと、サンドボックス化は、サンドボックスエンフォーサとサンドボックス内でアプリを正しく機能させる必要のある開発者の両方にとって適切な解決策であり、汎用のOSセキュリティが通常機能していないため、互換性がありません。多くのレガシーコード。

Linuxおよび同様のOSでサンドボックス化する初期のアプローチ chroot jails がよく使用されますが、それらはまだオプションです（正しく理解することは困難ですが）。ただし、現在、他にも構成可能で脆弱性の低いオプションがあります。 Docker のようなシステムを使用したプロセスの「コンテナー化」により、プロセスをシステムの他の部分から分離するのが比較的簡単になりますが、Docker自体は、あなたが説明するユースケース用に特別に設計されていません。それまたはそのテクノロジーをユーザーの用途に適合させることができる場合があります。

他のOSについては...

FreeBSDは、サンドボックスが処理する "jail"（ jail コマンドを使用）をサポートします。これはおそらく、サンドボックステクニックでLinuxを使用するのに最も類似しており、実際にほとんどのLinuxソフトウェアを実行し、同じハードウェアの多くをサポートします。
Androidアプリはサンドボックスで実行され、アプリパッケージの一部であるマニフェストで権限が指定されています。 Androidの最新バージョンでは通常、各アプリが取得するアクセス許可をきめ細かく制御できるため、アプリに必要なすべてのアクセス許可を与えるか、まったく実行しないかを決める必要はありません。。一般にデスクトップOSとしての使用を目的としたものではありませんが、利用可能なソフトウェアの範囲が非常に広く、ほとんどのハードウェアで実行することができます。
Chrom [e | ium] OS サンドボックス化されたアプリを実行し、本質的にOSとしてのWebブラウザーです。オンラインでほとんどの作業を行わない場合は、使用が制限されますが、新しいバージョンではAndroidアプリを実行することもできます。
MacOSはサンドボックスをサポートしており、アプリストアからインストールされたアプリに幅広く使用します。ただし、従来のMacOSアプリは引き続き完全な権限で実行されます。独自のソフトウェア（一部のオープンソースコンポーネントを含む）、および（合法的に）Appleハードウェアが必要です。
Apple iOSは、Androidと同じように、アクセス許可モードでサンドボックス化されたすべてのアプリを実行しますが、許可されている機能には制限があります。アプリはたくさんありますが、実行するハードウェア（iPad、iPhone、iPod Touch）に非常に制限があり、非常に独自仕様です。また、名目上の所有者に、デバイスに対する最小限の低レベルの制御を提供します。
Windows 10はアプリのサンドボックス化（アプリストアのアプリや一部の組み込みアプリで使用）をサポートしていますが、従来のほとんどのWindowsアプリは完全な信頼で実行されます（サードパーティのプログラムをサンドボックス化することは困難です）。独自のソフトウェアですが、最近のリリースではLinuxバイナリの実行をサポートしています（ただし、通常、特別なサンドボックスはありません。また、Linuxカーネルモジュールはサポートしていません）。