Linuxでパーティションをマウントするために管理者パスワードを要求するセキュリティ目的
それで、250GBのラップトップドライブを2つのパーティションといくつかのスワップに分割しました。 ext4 60GBパーティションである2番目のパーティションに、Fedora 17をインストールしました。他のより大きなNTFSパーティションには、Win XPと、両方のオペレーティングシステムを実行するときに使用するファイルがあります。
NTFSパーティションにアクセスしたいとき、Fedoraはそのパーティションをマウントするための管理者パスワードを尋ねてきました。なぜそれを行うのですか？ セキュリティの目的は何ですか？
起動するたびにNTFSパーティションをマウントするのは面倒です。私はこれを回避する方法について多くのガイドを見ていますが、私はそれらを理解せずに物事を変えようとするだけの人ではありません。
多分もっとまっすぐな質問は次のようになるでしょう：もし私が this を実行すると、それは私のシステムのセキュリティにどのように影響しますか？ Linuxで起動するたびにNTFSパーティションをマウントする必要がないようにするには、どうすればよいですか？
NTFSパーティションにアクセスしたいとき、Fedoraはそのパーティションをマウントするための管理者パスワードを尋ねてきました。なぜそれを行うのですか？セキュリティの目的は何ですか？
他の誰もが言ったように、パーティションをマウントし、/etc/fstabのエントリにrootフラグを設定するなどの特別な例外を除いて、パーティションをマウントするにはuserユーザーである必要があります。
理由これは制限することが重要です。これは、mountが他のディレクトリの上に任意のマウントポイントを重ねることができるためです。マウントを実行する権限があれば、/home/jeff/binを/binの上にmount /home/jeff/bin /bin -o bindを使用して配置できます。突然、すべての人がsu、lsのバージョン、またはディレクトリから希望する他のものを使用しています。
上記を実行するとわかるように、マウントポイントを空にする必要はありません。上にマウントされているディレクトリ内のすべてのものにアクセスできなくなります。 Mountは、パーティションだけでなく、ほぼすべてをディレクトリ構造にすることもできます。ループバックファイルシステムとリモートネットワークドライブもマウントソースとして使用できます。
したがって、マルチユーザーシステムでは、mountを使用してファイルシステム構造全体をウォークスルーすることはできません。セキュリティ制限を完全に破ってしまい、ファイルが予期した場所から来ているという想定は、誰かがそうする可能性があるためです。単に1つのディレクトリをマウントして、別のディレクトリをマスクします。
誰でも任意の場所に任意のファイルシステムをマウントできるようにすると、多くのセキュリティホールが開かれます。
- 明らかなのは、ファイルシステムドライバーが基になるデバイスにアクセスできるようになることです。これは、システム管理者がユーザーに公開したくないハードウェアである可能性があります。
- もう1つの明らかなのは、ユーザーが特権を取得できるファイルがある可能性があることです。たとえば、setuidルートシェル。または、メモリ、ディスク、またはその他のハードウェアリソースへのrawアクセスを許可するデバイスノード。ユーザーが任意のファイルシステムをマウントできるようにすると、任意の setuid/setgid プログラムと デバイスノード を作成できます。
- さらに微妙な問題は、ファイルシステムをマウントすると、予期しない場所にファイルが作成される可能性があることです。一部のアプリケーションは、固定された場所にあるファイルを読み取るか、ルートからファイルへのディレクトリのチェーンが1人のユーザーによって完全に所有されているファイルを信頼します。パスに沿って別のファイルシステムをマウントすると、マウンターが正当なファイルを任意のコンテンツに置き換えることができる可能性があります。たとえば、ルートパスワードが設定された別の
passwdファイルを使用して/etcのコピーをマウントできます。または、ユーザーのホームディレクトリの上に別のディレクトリをマウントして、独自の.ssh/authorized_keysを提供することもできます。 - もう1つの懸念は、ファイルシステムドライバーは、適切に形成されたファイルシステムでのパフォーマンスと信頼性を目的として作成されることが多いことです。ファイルシステムが不正な形式である場合、ドライバーにバグが発生し、基盤となるデバイスを制御するすべてのユーザーが、従来はカーネルで実行されていたファイルシステムドライバーのコンテキストでコードを実行できます。
/etc/fstab でデバイス、マウントポイント、マウントオプションを宣言して、起動時にファイルシステムを自動的にマウントできます。システムの場所に不明なファイルシステムをマウントしない、ルートファイルシステム以外でsetuidを無効にするなど、そこに「危険」なものを置かないのはシステム管理者の責任です。
通常のユーザーが一時ファイルシステムをマウントできるようにする昔ながらの方法は、usermount option をfstabに配置することです。通常はnoautoと組み合わせます。 userは、nosuid、nodevおよびnoexecの3つのオプションを自動的に意味します。これらのオプションは、setuid/setgidファイル（これらのビットは効果がない）、デバイスファイル（デバイスノードは効果がない）、および実行可能ファイル（実行可能ビットはディレクトリ以外では無視されます）をそれぞれ無効にします。 nosuidおよびnodevオプションは重要です。 noexecは、ほとんどすべての状況で無効にすることができます（execの後にuserを追加することにより）。次に、リムーバブルデバイスの典型的なfstab行を示します。
/dev/cdrom /media/cdrom iso9660 noauto,user,exec
ユーザーがリムーバブルデバイスをマウントできるようにするより現代的な方法は、 pmount プログラムをインストールすることです。このプログラムには、事前定義されたリストのみを許可するfstabよりも柔軟なポリシーがあります。 Pmountは、デバイスを取り外し可能として宣言し、マウントポイントを/mediaの下の空のディレクトリにする必要があるなど、いくつかの制約を適用します。
ネットワークリソースの場合、事前定義されたリストを超える従来のアプローチは automounter です。オートマウンターは通常、ユーザーがネットワークファイルシステム（NFS、Samba）のみを、検証済みホスト（または少なくともドメイン内のみ）からのみマウントできるように構成されており、nodevおよびnosuid 。
ユーザーがファイルシステムをマウントできるようにするためのより現代的なアプローチは、ファイルシステムドライバーをカーネルから移動することです。 Fuse は、ここではデファクトスタンダードです（Solaris、Linux、* BSD、OSX）。すべてのデバイスアクセスは権限のないプロセスによって実行されるため、ユーザーは基盤となるデバイス（存在する場合）にアクセスできる必要があります。同じ理由で、ファイルシステムドライバーのバグがオペレーティングシステムのセキュリティを危険にさらすことはありません。ユーザーはマウントポイントを所有している必要があるため、他の方法ではファイルを表示できない場所にファイルを表示できません。 Setuidおよびsetgidビットは無視されます。ただし、マウントを行っているユーザーだけでなく、任意のユーザーがファイルを所有するようにすることもできます。
Fedoraは私の管理者パスワードを尋ねました
Zzzが正しく言うように、パーティションをマウント/アンマウントできるのはrootだけです。実際、たとえば1024未満のポートへのバインドなど、多くのことができるのはrootだけです。
Rootユーザーが1人だけの場合、rootパスワードの共有が問題になります。さらに、rootを直接ログインできるようにすることは、WindowsのAdministratorアカウントの名前を変更するのと同じように、セキュリティリスクと見なされる可能性があり、共通のターゲットをそらすことができます。
Ubuntuは、インストール時にrootのランダムパスワードを生成し、/etc/sudoersのSudoを介してコマンドを実行できる特定のグループにrootアクセスを必要とするユーザーを追加することで、この問題を解決します。その後、ルートログインはブロックされ、Sudo、gksudoを介して通常のユーザーから、またはSudo -iを介してルートプロンプトから管理コマンドを実行できます。
Fedoraは途中まで進んでいます-rootログインは許可されていますが、wheelグループに属しているユーザーは（rootではなく）自分のパスワードでSudoを実行できます。これを可能にする/etc/sudoersの特定の行は次のとおりです。
%wheel ALL=(ALL) ALL
さて、2つの歴史的ノート：
- Fedoraのいくつかのコマンドは
Sudoの使用を認識せず、rootを必要とします。 Fedoraのrootコマンドは以前はsu -cを介して実行されていましたが、これはまだドキュメント内の場所で発生するため、ルートパスワードが必要になる場合があります。 - 歴史的に、
suは「ユーザーの切り替え」を表し、wheelグループはsuの実行を許可されたグループです。
そして、UNIXのセキュリティに関する最後の注意事項：
setuidおよびsetgidビットについて聞いたことがあるでしょう。これらは、プロセスを、誰が開始したかではなく、所有するユーザーとグループのコンテキストでそれぞれ実行できるようにします。これは、ユーザーがルートレベルの機能を必要とするプロセスを開始できるようにする従来の方法です。- これは実際には非推奨になりました-Fedoraはこれに優先してposix機能を採用しました。これは必要に応じてルート機能を分散し、多くのプロセスを非ルートで開始できるようにします。
[Windows XPインストールしていて、セキュリティが心配ですか？：p]
（オプション）現在、wheelグループ（システム管理者）の誰に対しても権限が昇格されています。特定のユーザーのみを選択できます。こちらです
これまでのところいいですね。マウント後にファイルシステムのアクセス許可を確認したいのですが、明示的には言及していません。例えば。 「mount」を実行し、このパーティションで「uid」マウントオプションを探します。でも大丈夫だと思う。
次に、Linuxユーザーが侵害されると、Windowsインストール全体、つまりWindowsを起動するとすぐにシステム全体が簡単に侵害される可能性があることを意味します。これは必ずしも大したことではありません。 Sudo/suを使用しているユーザーが危険にさらされると、すでに負けています。これがマルチユーザーシステムでない限り、ユーザーが危険にさらされると、キーボードで入力したパスワード、ファイル、電子メール、オンラインアクティビティなど、すべての重要な要素に影響します。また、特権昇格の脆弱性はかなり頻繁に発生します。
多層防御に取り組みたい場合は、パーティションを再編成して、共有データをWindows XPとは別のパーティションに置くことができます。すべてのデータをバックアップできる場合にのみこれをお勧めします。パーティションを再編成するときに間違いを犯す余地がたくさんあるためです。
または、カスタムのinitスクリプトを使用して同じ効果を実現することもできます。 FSを希望のuid =オプションでマウントし、共有データディレクトリを2番目のマウントポイントにバインドマウントしてから、元のマウントを解除します。とにかく、FATで動作することを確信しています。I- 希望それを迂回する卑劣な方法はありません-人々はセキュリティツールとして「ファイルシステム名前空間」を使用します、そしてそれはchrootのように既知の悪いことではありません。