fstabのnodevおよびnosuidの説明


44

誰かがtmpfsまたはramfsをマウントする方法を説明するときに、これら2つのオプションがWebで常に提案されているのを見ます。多くの場合、noexecも使用しますが、特にnodevとnosuidに興味があります。私は基本的に、誰かが示唆したことを盲目的に繰り返すだけで、本当の理解なしに嫌いです。そして、私はこれに関してコピー/貼り付けの指示だけをネット上で見るので、私はここで尋ねます。

これはドキュメントからです:
nodev-ファイルシステム上のブロックの特殊デバイスを解釈しないでください。
nosuid -suidおよびsgidビットの操作をブロックします。

しかし、これらの2つを除外した場合に何が起こるかについて、実用的な説明をお願いします。システム上の特定の(非root)ユーザーがアクセス(読み取り+書き込み)できるtmpfsまたはramfs(これら2つのオプションセットなし)を構成したとしましょう。そのユーザーはシステムに害を及ぼすために何ができますか?ramfsの場合に利用可能なすべてのシステムメモリを消費する場合を除く


1
これはあなたのQに良い答えです: unix.stackexchange.com/questions/188601/...
楕円ビュー

回答:


36

難しいルールとして盲目的にこれに従う必要はありません。しかし、よりセキュリティ重視の状況の理由は次のとおりです。

  • nodevマウントオプションは、ファイルシステムに特別なデバイスを含めることができないことを指定します。これはセキュリティ上の予防措置です。このようなユーザーがアクセスできるファイルシステムに、キャラクターデバイスの作成やランダムなデバイスハードウェアへのアクセスの可能性を持たせたくありません。

  • nosuidマウントオプションは、ファイルシステムにユーザーIDファイルのセットを含めることができないことを指定します。ルートエスカレーションなどのひどいリスクがあるので、誰でも書き込み可能なファイルシステムでsetuidバイナリを防止するのは理にかなっています。

それだけの価値があるので、私はこれらのパラメーターを頻繁に使用しません...他のコンプライアンスの考慮事項がある公共向けシステムでのみ。


1
ネットに公開されているアカウントでソフトウェアが実行されているため、実際に公開システムがあります。だから私はここでwhat-ifシナリオについて疑問に思っています。誰かが何らかの脆弱性を介してシェルアクセスを取得した場合はどうなりますか。もちろん、権利をエスカレートするために彼ができることは他にもありますが、私はそれらを最小限に抑えたいです。たとえば、suidの場合、ファイルシステムで許可されているかどうかに関係なく、ユーザーがそのフラグを変更することはできません。nosuidオプションは、誤って不適切に構成されたソフトウェア(ルートによる)を防止するだけですか?または、ユーザーが単独で悪用することはできますか?
イヴァンコヴァセビッチ

1
@IvanKovacevic推奨されるファイルシステムマウントオプションを使用する必要はありません。攻撃ベクトルを減らすためにあります。ただし、what-ifシナリオを調べることは、この質問の範囲を超える場合があります。
ewwhite

3
@ewwhite:nosuidsetuidビットは無視されないのか?(の代わりにThe nosuid mount option specifies that the filesystem cannot contain set userid files
-user2284570
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.