ブロックデバイスの所有権/許可の変更は、ファイルシステムのownershp / permsの変更と同等ですか？これはやりたいことですか？
私はこの質問に答えようとしました： r/wアクセスがないためディスクをfsckできません 。私が答えた：
答えは、
fsckの出力に含まれています。所有権の変更：
# chown username /dev/sdb5 $ fsck /dev/sdb5または、変更せずにルートになります（おそらくより良い）：
# fsck /dev/sdb5デバイスがマウントされている場合は、前にアンマウントします。
示唆されたfsck出力は次のとおりです。
ファイルシステムへのr/wアクセスまたはルートである必要があります。
次に、別のユーザーが私の答えで次のようにコメントしました：
ブロックデバイスの所有権を変更しないでください。これはセキュリティホールを開き、通常は通常のユーザーがバカなことをすることも防ぎます。したがって、あなたが説明するSudoオプションがその道です。たぶんあなたはあなたの答えを採用したいと思うでしょう。
そして、これは私を混乱させます。なぜなら、通常、ブロックデバイスでmkfsを実行してファイルシステムを作成するからです。 Sudo mkfs.ext4 /dev/block_device。そのため、そのファイルシステムとやり取りするには、ブロックデバイスファイルを介して行う必要があると想定しました。ここで、ファイルシステムが/ dev/block_deviceにある場合、ブロックデバイスの所有権または許可を変更すると、ファイルシステムの所有権または許可が変更されることになりますか？
私が間違った仮定をし、これらの事柄が同等でない場合、ファイルシステムの所有権または許可をどのように変更しますか？
それとも、やるべきではないのですか？どうして？
ブロックデバイスの所有者または所有権を変更しても、ファイルシステム内の何も変更しません。通常のユーザーに対してchownブロックデバイスを使用すると、ファイルシステムのアクセス権を完全にバイパスすることになります。
ブロックデバイスは、非構造化データを保持する単なるコンテナです。ファイルシステムは、これを構造化して使用可能にします。通常、すべてのユーザーはファイルシステムを介してブロックデバイスに間接的にアクセスし、ファイルまたはフォルダーの読み取り/オープン/書き込みを要求します。すべては、ファイルシステムによって維持されるアクセス権に基づいており、ファイルまたはフォルダーへのアクセスを許可または拒否します。
これで、通常のユーザーがブロックデバイスで読み取り/書き込みアクセスできる場合、ファイルをブロックデバイスから直接「スクラッチ」できるため、ファイルシステムのアクセス権をバイパスできます。
歩きましょう。
まず、rootによってのみアクセス可能なフォルダーとファイルを作成します。必要に応じてブロックデバイスから開始します。
root@Host:~# ll /dev/vda1
brw-rw---- 1 root disk 253, 1 Jul 26 18:52 /dev/vda1
root@Host:~# mkdir /secure-folder
root@Host:~# chmod 700 /secure-folder/
root@Host:~# ll -d /secure-folder
drwx------ 2 root root 4096 Jul 27 20:06 /secure-folder/
root@Host:~# echo "MySuperSecretText" > /secure-folder/my-secure-file
root@Host:~# chmod 400 /secure-folder/my-secure-file
root@Host:~# ll /secure-folder/my-secure-file
-r-------- 1 root root 9 Jul 27 19:19 /secure-folder/my-secure-file
このフォルダーとファイルにはrootユーザーのみがアクセスでき、ブロックデバイスの所有者を変更した後でも、期待どおりです。
user@Host:~$ ll /secure-folder/
ls: cannot open directory /secure-folder/: Permission denied
user@Host:~$ ll /secure-folder/my-secure-file
ls: cannot access /secure-folder/my-secure-file: Permission denied
root@Host:~# chown user /dev/vda1
root@Host:~# ll /dev/vda1
brw-rw---- 1 user disk 253, 1 Jul 27 20:16 /dev/vda1
user@Host:~$ ll /secure-folder/
ls: cannot open directory /secure-folder/: Permission denied
user@Host:~$ ll /secure-folder/my-secure-file
ls: cannot access /secure-folder/my-secure-file: Permission denied
この場合、ファイルシステムは、userがアクセス権を持っていないファイルにアクセスすることを妨げています。
ただし、userにはブロックデバイスへの読み取り/書き込みアクセス権があるため、ファイルシステムをバイパスできます。 vda1は/にマウントされているパーティションで、debugfsにはe2fsprogsが付属しているため、プリインストールされていることは間違いありません。
user@Host:~$ debugfs /dev/vda1 -R "ls -l /secure-folder"
67344 40700 (2) 0 0 4096 27-Jul-2017 19:33 .
2 40755 (2) 0 0 4096 27-Jul-2017 19:16 ..
45137 100400 (1) 0 0 18 27-Jul-2017 19:43 my-secure-file
申し分なく、アクセス権のないフォルダのディレクトリエントリを一覧表示できます。私がアクセス権を持っていないファイルに対して他に何ができるか見てみましょう。
user@Host:~$ debugfs /dev/vda1 -R "cat /secure-folder/my-secure-file"
debugfs 1.42.9 (4-Feb-2014)
MySuperSecretText
さて、この方法でファイルの内容を読むことができます。クール。他に何ができますか？普段はできない場所にフォルダーを作成しましょう。
user@Host:~$ debugfs -w /dev/vda1 -R "mkdir /secure-folder/attack"
debugfs 1.42.9 (4-Feb-2014)
root@Host:~# ll /secure-folder/
total 16
drwx------ 2 root root 4096 Jul 27 19:33 ./
drwxr-xr-x 25 root root 4096 Jul 27 19:16 ../
drwxr-xr-x 2 root root 4096 Jul 27 20:29 attack/
-r-------- 1 root root 18 Jul 27 19:43 my-secure-file
おっと。私はrootとして作成しましたが、userにも属します。うーん、他に何が可能でしょうか？やってみよう。
まず、/secure-folder/my-secure-fileのブロック番号が必要です。
user@Host:~$ debugfs /dev/vda1 -R "blocks /secure-folder/my-secure-file"
debugfs 1.42.9 (4-Feb-2014)
913939
さて、ブロック番号913939にはファイル/secure-folder/my-secure-fileのデータが含まれています。 ddを使用してコンテンツを取得しましょう。4096はext4またはxfsファイルシステムのデフォルトのブロックサイズです。ここでも、通常のユーザーとしてブロックデバイスで操作できるため、可能です。
user@Host:~$ dd if=/dev/vda1 of=/tmp/secure-file skip=913939 bs=4096 count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.0214174 s, 191 kB/s
これで、/tmp/secure-fileとddを変更して、ブロックデバイスに戻すことができます。
user@Host:~$ cat /tmp/secure-file
XxXxxxxSecretText
user@Host:~$ dd if=/tmp/secure-file of=/dev/vda1 seek=913939 bs=4096 count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000356448 s, 11.5 MB/s
最後に、rootユーザーとして、ファイルシステムビューからファイルを見てみましょう。安全にするために、まずすべてのキャッシュを無効にしてディスクのコンテンツを取得します。
root@Host:~# echo 3 > /proc/sys/vm/drop_caches
root@Host:~# cat /secure-folder/my-secure-file
XxXxxxxSecretText
root@Host:~# ll /secure-folder/my-secure-file
-r-------- 1 root root 18 Jul 27 20:39 /secure-folder/my-secure-file
通常のユーザーとしてrootに属するファイルを変更しましたが、アクセス権を変更する必要はありません。すべては、基礎となるブロックデバイスへの読み取り/書き込みアクセスがあったという事実に基づいています。
これは単純な例に過ぎず、高度な攻撃者がバイナリコードをファイルシステムに配置したり、既知のバイナリを悪意のあるバイナリと交換したりする可能性があります。通常、使用されるツールは、ほぼすべてのディストリビューションにプリインストールされています。
まあ、udevでリブートするとブロックデバイスのアクセス権が元に戻されることを認める必要がありますが、ブロックデバイスに対する通常のユーザーに読み取り/書き込みアクセスを許可すると、セキュリティの問題が発生します。
混乱しすぎず、ファイルシステムとブロックデバイスの違いを理解するのに役立つことを願っています。
あなたはその意味を誤解していると思います。 Sudoグループのメンバーとして、デフォルトでR/Wアクセスができます。これは、実際にルートであることを意味するのではなく、Sudoの構成方法 に応じて同様のアクセス権があることを意味します。
参考文献：
https://help.ubuntu.com/community/Sudoers
https://www.tecmint.com/su-vs-Sudo-and-how-to-configure-Sudo-in-linux/