When you change the owner or ownership of the block device, you do not change anything in the filesystem. What happens if you chown the block device to a normal user is, that you completely bypass the filesystem access rights.
A block device is just container that holds unstructured data. The filesystem makes this structured and usable. Normally all users access the block device indirectly through the filesystem, asking to read/open/write files or folders. All based on the access rights that are maintained by the filesystem, granting or denying access to a file or folder.
Now when a normal user has read/write access on a block device, one can bypass those access rights of the filesystem as you can "scratch" files directly form the block device.
Let's walk through.
First we create a folder and file that is only accessible by root, starting with a block device as it should be.
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
This folder and file can only be accessed by the root user and even after changing the owner of the block device, it is still as you would expect.
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
In this case your filesystem is preventing the user from access files that it does not have access rights to.
But since the user has read/write access to the block device, we can bypass the filesystem. vda1 here is the partition that is mounted on / and debugfs comes with e2fsprogs, so is pretty sure preinstalled.
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
Alright, I can list the directory entries in a folder I do not have access rights. Let's see what else can be done on a file that I do not have access rights on.
user@host:~$ debugfs /dev/vda1 -R "cat /secure-folder/my-secure-file"
debugfs 1.42.9 (4-Feb-2014)
MySuperSecretText
Alright, I can read contents of files this way. Cool. What else could I do? Let's create a folder in a place I normally couldn't.
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
Ooops. It even belongs to root although I have created it as user. Hm, what else would be possible? Let's try.
First we need the block number of the /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
Okay, block number 913939 contains the data of the file /secure-folder/my-secure-file. Let's use dd to get the content, 4096 is the default block size of ext4 or xfs filesystems. Again possible because I can operate on the block device as a normal user.
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
Now we can modify /tmp/secure-file and dd it back on the block device.
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
Last, as root user let's have a look at the file from the filesystem view. To make it safe we first invalidate all caches to get the content of the disk.
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
I have changed a file that belongs to root as normal user and did not have to change any access rights. All based on the fact that I had read/write access to the underlying block device.
This is only a simple example and an advanced attacker could place binary code in your filesystem or exchange well known binaries with malicious ones. Normally the tools used are preinstalled on nearly any distribution.
Well, I must admit that the access rights on the block device are set back when you reboot by udev, but it opens a security issue when you give read/write access to a normal user to a block device.
Hope it's not too confusing and helps to understand the difference between the filesystem and the block device.
sudofor all intents and purposes runs a command with root permissions.suorsudo. I'm just curious and probably a bit confused by the terminology. The main reason for my confusion being thatfsckmessage, why does it seem to imply that it is ok to change a filesystem/block device's permissions (again, not sure about how these two things relate to each other)?