ブロックデバイスに brwx______ の権限がある場合、どの程度安全ですか?

ブロックデバイスに brwx______ の権限がある場合、どの程度安全ですか?

ブロック デバイスの権限が実際に何を意味するのかに関する情報を見つけるのに苦労しています。ブロック デバイスの場合、読み取り権限とは何を意味しますか? hexdump などの操作ができないことを意味しますか? 書き込み権限はどうですか? または実行権限はどうですか?

さらに、ユーザーに特定のデバイスのみをマウントする sudo 権限を与え、デバイスに対する r、w、x 権限を与えずにマウント権限を持つ場合はどうなるでしょうか。その場合、何が起こるでしょうか。

答え1

単純なケース(ファイルのようにデバイスにアクセスする場合)では、@Jasen が書いたとおりです。

  • 読み取り権限により、デバイスからの読み取り(ダンプ、fsck読み取り専用モードでの実行など)が可能になります。
  • 書き込み権限は、デバイスへの書き込み(イメージによる上書きなど)を許可します。
  • fscktune2fsなどを実行するには、両方の権限が必要です。そしてファイルシステムを変更します。
  • 実行権限は無視されます。デバイス ファイルを実行しようとすると、ブロック デバイスに有効な実行可能コードが含まれていても、「権限が拒否されました」というメッセージが表示されます。

ルート権限を持っている場合は、通常CAP_DAC_READ_SEARCHCAP_DAC_OVERRIDE 機能つまり、権限フラグは完全に無視されます。

のためにioctlもっと複雑です:

ioctlを実行するには、開けるつまり、少なくとも読み取りまたは書き込み権限が必要です。

その他はすべてドライバに依存します。デバイス ドライバの中には、CAP_SYS_RAWIOや のような機能のみをチェックするCAP_SYS_ADMINものもあれば、情報のみを提供する「無害な」ioctl に読み取り権限を使用し、他の ioctl に読み取り + 書き込み権限を使用するものもあります。デバイス ドライバは、ioctl 権限チェックに実行権限を使用することがありますが、これを行うドライバは知りません。

のためにマウントもっと簡単です:

システムmountコールは次の 2 つの点のみをチェックします。

  1. できることが必要です到着デバイス ファイル。つまり、デバイス ファイルへのパス上のすべてのディレクトリに、少なくとも実行許可ビットが設定されている必要があります (または、そのCAP_DAC_READ_SEARCH権限を持っている必要があります)。
  2. 権限が必要ですCAP_SYS_ADMIN(これも通常、root 権限があれば取​​得できます)

デバイス ファイル自体の権限ビットはマウント時に完全に無視され、マウントされたファイル システムへのアクセスにはまったく影響しません。

使用須藤実行されたプログラムは、利用可能なすべての権限を持つルートとして実行されます。つまり、すべての権限チェックは無視され、@Jasenがコメントで書いたように、通常はsetuid-rootであるため、常に利用可能なすべての権限が取得されるため、ほとんどのLinuxディストリビューションで/bin/mountは権限ビットは影響しません。mountおよびその他のUnix系オペレーティングシステム

編集:機能に関する部分は Linux に固有のものです。BSD や OSX などの他の Unix 系オペレーティング システムでは、root の特殊能力が機能に分けられていないため、機能について言及されている場合は、単に root である必要があります。利用可能なマニュアル ページに基づくと、チェックは、mount私が説明した Linux 固有のチェックに似ています。マウント時に権限ビットをチェックする OS はないようです。

答え2

read は読み取りを許可します (例: hexdump)。write は書き込みを許可します (例: デバイスへのイメージの書き込み)。これらを組み合わせると、「hexedit」などのツールを使用してコンテンツを表示および変更できます。

x が何を許可するかはわかりません (ioctl を許可する可能性はありますか?)

権限が設定されているため、brwx______所有者 (通常はroot) だけがそれらの操作を実行できます。

関連情報