ルートセキュリティが実施されているのに、$ HOMEは通常保護されていないのはなぜですか？
この質問のコメントから来る rootとしてログインするのはなぜ悪いのですか？ ：
Sudoメカニズムが使用されているため、非管理ツールは「システムに害を及ぼすことはありません」。私がクローンしたgithubプロジェクトが悪意のあるコードを/binに挿入できたら、それはかなり悪いことだと私は同意します。しかし、デスクトップPCの場合はどのような理由がありますか？同じgithubコードを実行すると、Sudo権限がなければ、ホームフォルダー全体を一掃したり、キーロガーを自動開始セッションに配置したり、~で好きなように実行したりできます。
バックアップがない限り、ホームフォルダーは通常一意であり、機密データではないにしても貴重なデータが含まれています。ただし、ルートディレクトリはシステムを構築し、多くの場合、システムを再インストールするだけで回復できます。 /varなどに保存された構成がありますが、2011年の休日の写真よりもユーザーにとって重要ではない傾向があります。rootアクセス許可システムは理にかなっていますが、デスクトップシステムでは、間違って保護しているように感じますデータ。
$HOMEで悪意のあるコードが発生するのを防ぐ方法はありませんか？そして、なぜ誰もそれを気にしないのですか？
私は、Unixセキュリティモデルの時代やそれが開発された環境に問題があるという答えには同意しません。これを処理するためのメカニズムがあるため、そうではないと思います。
ルート権限システムは理にかなっていますが、デスクトップシステムでは、間違ったデータを保護しているように感じます。
スーパーユーザーの権限は、ユーザーをシステムから保護するために存在します。ユーザーアカウントの権限は、他の非rootアカウントからアカウントを保護するためにあります。
プログラムを実行することにより、UIDを使用して何かを実行するためのアクセス許可をプログラムに付与します。 UIDにはホームディレクトリへの完全なアクセス権があるため、プログラムに同じアクセス権を推移的に付与しました。スーパーユーザーが悪意のある動作（パスワード、構成、バイナリ）からの保護を必要とするシステムファイルに変更を加えるアクセス権を持っているのと同じように、ホームディレクトリに同じ種類の保護を必要とするデータがある可能性があります。
最小特権の原則 は、必要以上のアクセスを許可してはならないことを示しています。プログラムを実行するための決定プロセスは、システムファイルの場合と同様に、ファイルに関しても同じである必要があります。システムを保護するためにスーパーユーザーアカウントを無制限に使用することを信頼しないコードを提供しない場合、データを保護するためにアカウントを無制限に使用するべきではありません。
$ HOMEで悪意のあるコードが発生するのを防ぐ方法はありませんか？そして、なぜ誰もそれを気にしないのですか？
Unixは、同じ理由できめ細かいアクセス許可を提供しません rmコマンドの周囲にブレードガードはありません ：アクセス許可は、ユーザーを自分自身から保護するためのものではありません。
悪意のあるコードがホームディレクトリのファイルに損傷を与えるのを防ぐ方法は、アカウントを使用して実行しないことです。特別な権限を持たない別のユーザーを作成し、信頼できるかどうかが決まるまで、そのUIDでコードを実行します。
これを行う方法は他にもあります。たとえば、chrootされた刑務所などですが、それらを設定するにはより多くの作業が必要であり、それらをエスケープすることは、かつての課題ではなくなりました。
NIXベースのセキュリティモデルは50年前なので
UNIXは、最も普及しているOSの基礎を成しており、大きな例外であるWindowsも、見かけ以上に影響を受けています。これは、コンピュータが秘儀の専門家だけが使用する大型で高価な低速マシンだった時代に由来しています。
当時、ユーザーは任意のコンピューターではなく、大学のサーバーや個人のコンピューター（そして確かに携帯電話）ではなく、広範囲の個人データを収集していませんでした。ユーザーごとに異なるデータは、通常、科学計算プロセスの入力データと出力データでした。これらを失うと損失となる可能性がありますが、大部分はそれらを再計算することで埋め合わせることができ、確かに今日のデータ漏洩の結果とは異なります。
誰も自分の日記、銀行情報、またはヌード写真をコンピューターに持っていなかったでしょうから、悪意のあるアクセスからそれらを保護することは優先度の高いものではありませんでした-実際、ほとんどの学部生70年代は、他の人が彼らの研究データに興味を示したとしたら、おそらくわくわくしたでしょう。したがって、データの損失を防ぐことはコンピュータセキュリティの最優先事項であると考えられており、これはアクセス制御ではなく定期的なバックアップによって十分に保証されています。
これは非常に鋭い観察です。はい、ユーザーとして実行しているマルウェアは、ホームディレクトリのデータを損傷/破壊/変更する可能性があります。はい。シングルユーザーシステムでのユーザー分離は、サーバーよりも有用ではありません。ただし、rootユーザー（または同等のユーザー）しか実行できないことがいくつかあります。
- カーネルにルートキットをインストールします。
- 永続化のための初期のバックドアを含むようにブートローダーを変更します。
- ハードディスクのすべてのブロックを消去して、データを回復不能にします。
正直なところ、ワークステーションでの特権の分離は、ワークステーションを最大の敵である私から保護するのに最も役立ちます。それは私のシステムを台無しにして壊すのを難しくします。
さらに、ホームディレクトリのバックアップ（rsnapshotなど）を作成し、ユーザーが書き込みできないように保存するcronジョブをrootとしていつでも設定できます。それは、あなたが説明する状況ではある程度の保護になるでしょう。
Unix/Linuxセキュリティの元々の設計は、ユーザーを他のユーザーから保護し、システムファイルをユーザーから保護することでした。 30〜40年前、ほとんどのUnixシステムはマルチユーザーセットアップで、多くの人が同時に同じマシンにログインしていたことを思い出してください。これらのシステムは数万ドルの費用がかかり、自分の個人用マシンを所有することは非常にまれであったため、そのマシンはマルチユーザーログイン環境で共有されていました。
この設計は、ユーザーまたはユーザーファイルを悪意のあるコードから保護するためのものではなく、ユーザーを他のユーザーから保護したり、ユーザーが基本システムを変更したり、ユーザーがシステムリソースを過度に使用したりしないようにするためのものです。誰もが自分のコンピューターを所有する現在の時代では、デザインは（ほとんどの場合）1つのプロセスが多くのシステムリソースを占有するのを防ぐシングルユーザーマシンに変換されています。
このため、ユーザーが実行したプログラムは、ユーザーが所有するすべてのファイルにアクセスできます。ユーザー自身のファイルにこれ以上アクセスするという概念はありません。つまり、ユーザーAとして実行されたプロセスは、ユーザーAに属するすべてのファイルを読み取り、変更、および削除するアクセス権を持っています。これには、（お気付きのとおり）自動起動ファイルが含まれます。
より最近のアプローチでは、特定のファイルをさらに制御する必要があります。これらのファイルにアクセスするために「再認証が必要」などの何か、またはあるプログラムファイルを別のプログラムファイルからさらに保護する何らかの形。私の知る限り、Linuxデスクトップの世界では、このようなことは（現在のところ）ありません。私が間違っている場合は私を修正しますか？
$ HOMEで悪意のあるコードが発生するのを防ぐ方法はありませんか？
この質問に答えるために、一部のインストールでは、ユーザーにプログラムを実行させることにより、既存のセキュリティフレームワークを利用します。プログラムには、実行するユーザーを指定する構成オプションがあります。たとえば、私のPostgreSQLインストールには、ユーザーpostgresが所有するデータベースファイルがあり、データベースサーバーはpostgresとして実行されます。 PostgreSQLの管理コマンドについては、ユーザーをpostgresに変更します。 OpenVPNには、rootの管理機能を使用して（ネットワークインターフェイスなどを追加するために）完了した後で、権限のないユーザーに変更するオプションもあります。インストールには、特にこの目的のためにnobodyという名前のユーザーがいる場合があります。このように、PostgreSQLまたはOpenVPNでの悪用は、必ずしも$HOMEの侵害につながるわけではありません。
別のオプションは、SELinuxのようなものを使用して、各プログラムがアクセスできるファイルとその他のリソースを正確に指定することです。このようにして、ルートとして実行されているプログラムが$HOMEのファイルに触れることを拒否することもできます。各プログラムを指定する詳細なSELinuxポリシーを作成するのは面倒ですが、Fedoraのような一部のディストリビューションは途中まで進み、ネットワークに面するプログラムに追加の制限を追加するだけのポリシーが定義されていると思います。
質問の2番目の部分に回答するには：サンドボックスメカニズムがありますが、ほとんどのLinuxディストリビューションではデフォルトで有効になっていません。
非常に古くて複雑なのはselinuxです。より新しく、より使いやすいアプローチはapparmorです。個人的な使用に最も役立つ（apparmorおよびsimiliarシステムは主にデーモンの保護に使用されます）は firejail であり、プロセスを自分の刑務所に隔離します。
たとえば、Firefoxはプロファイルディレクトリとダウンロードディレクトリのみを書き込むことができます。一方、画像をDownloadsディレクトリに配置しないと、画像をアップロードできません。しかし、これはそのようなサンドボックスの設計によるものです。プログラムが画像を削除したり、ランダムなサイトにアップロードしたりする可能性があるため、刑務所ではこれを防ぎます。
Firejailの使用は簡単です。あなたはそれをインストールし、すでにプロファイルを持っているプログラム（/etc/firejailを調べます）に対しては（rootとして）ln -s /usr/bin/firejail /usr/local/bin/firefoxを実行するだけです。 rootでないか、firejailのコマンドライン引数（プロファイルファイルへのカスタムパスなど）を使用する場合は、firejail firefoxを実行できます。
Snapのようなシステムでは、サンドボックスメカニズムも追加する必要があるため、ランダムスナップリポジトリからインストールされた信頼できないプログラムを、あまり影響を与えずに実行できます。これらのメカニズムをすべて使用しても、信頼されていないプログラムがスパムの送信やdDoS攻撃の一部になるなどの処理を実行できることに留意してください。
間違ったデータが保護されているという推定は誤りです。
rootアクティビティの保護は、2011年の休暇の写真を保護します。そして、私のもの、そしてあなたの兄弟たち、そしてコンピューターを使用する他のすべての人たち。
アプリがファイルにアクセスしようとするたびにパスワードを要求することでホームアカウントを保護するスキームでOSを実装し、ルートパスワード保護を削除したとしても、worseになるので使用しません。 =それらの休暇の写真。
私の兄弟がホームコンピューターのコアシステム機能を危険にさらしている場合、システム自体が危険にさらされ、ユーザーレベルの制限を回避できるため、ホームディレクトリの保護にかかわらず、休暇の写真が削除されたり、身代金が消費されたりします。 。
また、ほとんどの人は、選択するたびにパスワードを入力しなければならない場合、非常に煩わしいでしょうFile -> Openワープロで。
また、自宅のコンピュータでアクセス制御が頻繁に要求されるという問題もありました。マイクロソフトが最初にUACを公開したとき（メインアカウントを使用している場合はパスワードを入力する必要すらありません...ボタンを押すだけです）、それはたくさん出てきて、人々は彼らの人生の0.5秒が1日20回無駄にされ、Microsoftがそれを変更したと十分に不満を述べました。さて、これはあなたが話している種類の保護ではありませんでしたが、人々がMicrosoftのシステムセキュリティのために1日に数十回セキュリティボタンをクリックすることを望まない場合、彼らはクリックしたくないでしょう。 （さらに悪いことに、パスワードを入力します）実行したランダムアプリから写真を保護するために実装するものは何でも。
したがって、基本的な答えは次のとおりです。
- ルートを保護すると、個人の写真が保護されます。
- この種の認証が頻繁に要求されることについて人々は不満を述べています。
他の回答はwhyを見てください* nixは現状のままです。
しかし、ユーザーのホームディレクトリ、スクリプト、およびファイルを保護するために、「すぐに使える」構成よりも少し多くのことを実行する余地があることは注目に値します。
最新の* nixは、POSIXまたはバリアントACLをサポートしています。これらは、OPが探している細かいアクセス制御の種類を追加するように構成できます。それらは手動で設定する必要があり、どのユーザー/グループアカウントが機能しているか以外の基準でアクセスを区別しようとはしません。ただし、いったん設定すると、どのアカウントがファイルに対してどのアクションを実行できるかを非常に具体的に指定でき、コマンドが特定のコマンドまたはファイルに対してすべてに対して1つのユーザーアカウントではなく、制限されたアカウントを使用するように強制することで、少なくともいくつかの追加制御を取得できます。ただし、実用性にはかなり厳しい制限があります。
ルート/カーネルを保護する重要なポイントの1つは法医学的整合性です。貴重なデータ（プライベートドキュメントとWeb認証トークンを使用するデスクトップユーザー、機密コード/リソースを使用する開発サーバー、ユーザーデータベースを使用するwebappサーバーなど）を含むドメインが侵害された場合、あなたはまだ妥協しないdomainそこから、妥協点を評価し、何が起こったかを判断し、まったく同じことが再び起こるのを防ぐための計画を立てるなど。
そのような特権は不便なので存在しません。
パーミッションの目的は、一般に、望ましくないアクションを防ぐことです。 rootが実行できる種類のアクションは、はるかに油断ならないものです。ユーザーレベルのランサムウェアアプリはファイルを暗号化できる場合がありますが、暗号化しているという事実を隠すことはできません。暗号化されたファイルを見つけると、通常と同じように開かれ、暗号化されていることがわかります。ルートレベルのランサムウェアを使用すると、ファイルシステム全体を乗っ取り、ファイルが最後まで暗号化されないように見せかけ、キーとbam！すべてのファイルに同時にアクセスできなくなります。
現在、明らかに今日ではrootとしてログインしていません。須藤を使用しています。これは、役割ベースの特権の形式です。 「管理タスクを実行するユーザー」の役割を引き受けるまで、root権限はありません。その後、コマンドを完了するまで、それらの特権を取得します。
1つのcouldは、さまざまなフォルダにアクセスできる細かい役割を作成します。おそらく、「休暇の写真」を読み取り専用にしたいnless「写真の追加/編集」ロールを入力します。これは強力ですが、負担になります。 Aaronが述べたように、WindowsのUACは、物事を行うだけでなく、許可を求める貴重な数秒を浪費したことで広くパンニングされました。データを保護するために役割を切り替える必要がある場合、コンピューターはより頻繁に許可を求める必要があります。ユーザーはこれが価値があるとは一般に思っていないため、サポートされていません。
（そのような機能に興味があり、Sudoを使用してそれらを実行したい場合は、目的に応じてroまたはrwにマウントできる個別のパーティションを作成し、そこに写真を保存できます）。
このような場合に対処するのが最も難しいタスクの1つは、ロールの細分性です。 serが何らかの役割を果たした場合、その処理は非常に簡単です。ただし、特定のアプリケーションがその役割に入る必要がある場合を処理することは困難です。 Firefoxはあなたの写真への書き込みを許可されていないかもしれませんが、GIMPは許可されています。境界がある場所では、一貫したシームレスな統合ができないため、これはトリッキーです。 FirefoxがGIMPプラグインを利用して写真編集を行う場合はどうなりますか？ Firefoxがこれを行わないようにする唯一の方法は、FirefoxがGIMPと通信できないようにすることです。
私は、あなたがWindowsの経験があることを前提としています。 UACが表示されたときに画面が暗くなる理由を考えたことはありますか？実際にはnotであり、特別なことをしていることを視覚的に確認できます。それよりもはるかに重要です。淡色表示部分の上のウィンドウは、下のウィンドウから分離された別の画面の一部です。何でこれが大切ですか？さて、画面上の任意のウィンドウが同じ画面上の他のウィンドウを操作することが許可されていることがわかります。 UACがインストーラプログラムと同じ画面でアクセス許可を要求した場合、インストーラは文字通り UACウィンドウへのハンドルを取得そしてOKをクリックしてください！それは確かにそのようなプロンプトの目的を無効にします。解決策は、UACがdifferent画面で提供されるため、他のアプリケーションが単独で[OK]をクリックできないようにすることです。 OKをクリックする唯一の方法は、ユーザーがマウスを動かしてクリックすることです。暗くなるのは、UAC画面がキーボード/マウスを制御している間は、その下のウィンドウを操作できないことを示すためだけにあります。
これが、分離のために行わなければならない努力のレベルです。簡単ではない。実際、複数のユーザーアカウントを持ち、それぞれにデータへの異なるアクセス権を付与することで、主要なデータを保護するのは意味のあることです。次に、ユーザー切り替え機能を使用して、それらを切り替えることができます。これは、適切なロールベースの権限を実行するために必要な種類の分離を提供します。
Unixは実際にはデスクトップシステムではありません。これは、大学の地下のどこかにある家と同じくらいの費用がかかる大型コンピューターで実行されるシステムです。自分のコンピュータを買う余裕のない人として、あなたはそのコンピュータを他の2000人と共有し、さらには数十人のユーザーと同時に共有する必要があります。
偶然にも、最近はまたはデスクトップコンピュータまたは$ 20のクレジットカードサイズのSoCでUnixライクなシステムを実行できます。
ただし、原則として、Unixはシングルユーザー向けに設計されていません。シングルユーザーは重要ではありません。あなたのホームディレクトリにあるのはあなたの問題ですが、rootができることはみんなの問題です。したがって、rootとして実際に作業する必要があるいくつかのタスクのみをそのユーザーで実行する必要があります。そのアカウントでログインするのではなく、Sudoを明示的に使用してそれを必要とする単一のコマンド。その中には多くの信仰があります。そのため、一部のディストリビューターは傲慢な態度で、suではなくSudoと入力すると、ささいなものをインストールするために実行する必要がある10個のaptコマンドのすべてに対して、あなたを脅迫することがあります。 この事件は報告されます、よくあなたに何を伝えて、あなたの報告をファックしてください。一部の人々は本当に他の人から地獄を悩ませる方法を知っています。
したがって、rootにならずにすべての個人的な写真を消去できます。そのとおり。マルウェアは、ホームディレクトリ内のすべてのものを消去する可能性があります。ユーザークォータに達するまでディスクをいっぱいにすることで、サービスを拒否できます。しかし、システムの観点からは、それは単にあなたの問題であり、他の誰も気にしません。他のユーザーは（原則として）影響を受けません。
さて、現代の単一（または少数）ユーザーシステムの問題は、「何百ものユーザーがいる」という考え方のように、2価論理セキュリティモデルがまったく適用できないことです。
残念ながら、より良いものを思いつくことは非常に困難です。アイデアを盗まない方法を知りたい場合はWindowsを見てください（彼らは本当に悪いアプローチをさらに悪化させることができました）。
一部のWebブラウザーと電話（またはスマートTV）オペレーティングシステムは、より良いものを提供しようとします（そして失敗します）。また、最近のLinuxもよりきめの細かいシステムを備えています（しかし、支出せずに適切に設定する方法がわかりません- 週私の時間の）。
問題は、2価セキュリティモデルが通常のアプリケーションが特権を必要としないことを想定していることです（ほとんど無害なものは特権を必要とするため、これは間違っています）一方で、通常でないアプリケーションはコンピューターシステムへのフルアクセスを必要とします（これも間違っていますが、ほとんど完全なアクセスを必要とするプログラムはありません）。
一方、さらに細かいセキュリティモデル（まだかなり粗い）では、アプリケーションが一連の特権を要求する場合、その完全なセットが本当に必要であり、ユーザーはそれを許可することに抵抗がないという誤った仮定をします。
私の知る限りでは、アプリケーションが特権A、B、およびCを要求できるシステムはなく、ユーザーはA（BおよびCではなく）の付与に同意でき、アプリケーションは付与された特権を照会できます。そして、要求されたタスクを実行できるかどうかを決定します。
したがって、通常はXYZ-appに「永続的なストアにデータを保存する」（これで大丈夫かもしれません）を許可するという選択肢がありますおよび「位置情報へのアクセス」と「個人データへのアクセス」を許可するまたは「システムドライバをインストールする」（これは問題ありません）、またはプログラムを実行できません。
または、XYZプログラムに「コンピュータに変更を加える」ことを許可することができます。つまり、実行しないように選択することもできます。そして、毎回それを確認する必要があります。正直なところ、これはユーザーの観点からは本当にうんざりです。
$ HOMEで悪意のあるコードが発生するのを防ぐ方法はありませんか？
個別のマウントポイントとして/homeがあり、それが独自のパーティションにあるとすると、/etc/fstabを簡単に編集して、マウントオプションにnoexecフラグを追加できます。これにより、そのパーティションでのすべてのコード実行が無効になり、~/bin内のコードの欠点（ユーザーごとのインストールによって作成される可能性があるため）も実行されなくなります。それでも、ファイルシステム内の他の場所にある実行可能ファイルが/homeを一掃するのを停止することはありません。
SE Linux は完全に本格的なセキュリティシステムであり、適切に分離できますが、AppArmorはアプリケーションの分離のみを目的としています。 Androidの基盤となるLinuxは、v 5.0からそれを備えています。 Windowsで、彼らは最近、まったく同じ（完全なはぎ取り）の「保護フォルダー」を導入しました。ここでの欠点は、何か新しいものを手動でインストールするときに、適切なフラグを付けたり設定したりして、それを許可する必要があることです。人々はそれを処理する方法を理解していないという理由だけで、それを無効にすることをしばしば提案します。まあ、これはデプロイメント用にSE Linuxディストリビューションを選択するポイントとは厳密には一致しません。
誰も次のことを言っていないことに驚きます。
Rootとしてデスクトップマシンにログインしない主な理由の1つは、多くのアクティビティがファイルの所有権をrootに変更するためです。これは一般に、「通常の」ユーザーはrootによって作成されたデフォルトの構成ファイルを読み取ることができないため、多くのアプリケーションを実行できないことを意味します。
サーバーマシンにrootとしてログインしない主な理由の1つは、監査/トレーサビリティの観点から、誰かが自分でログインし、rootとしてコマンドを実行して、「user1」を示す監査可能なログが存在するようにすることです。ログインしてから「root」がIPアドレス10.2.1.2からログインしたことだけを知るのではなく、rootに切り替えました。これは、多くの人が利用できる汎用端末である可能性があります。サーバーマシンでは、管理者が実行するアクションをより監査可能かつ追跡可能にするために、多くのコマンドへのSudoアクセスを制限することがより一般的です。
すべてのルートアクティビティと同様に、好きなことを実行できます。やればいけないほど、あなたの足に向けられる銃のサイズが大きくなり、その引き金を引くのに間違ったコマンドが1つだけかかることを覚えておいてください。
rm -rf {uninitializedVariable}/*