1

An ideally least privileged process should be able to have readonly access to data on a filesystem, which itself is readonly. Hence this is the situation

root@linux# ###(1) filesystem is untrusted + readonly
root@linux# grep untrusted_ro_fs /proc/mounts       
/dev/sdb1 /mnt/untrusted_ro_fs ext4 ro 0 0

root@linux# ###(2) no read permissions for (o)thers for /mnt/untrusted_ro_fs/root root@linux# ls -ld /mnt/untrusted_ro_fs/root drwxr-x--- 1 root root 1138 Jul 3 21:13 /mnt/untrusted_ro_fs/root

root@linux# ###(3a) unpriviledge process ls (run with uid=9999 and gid=9999) no read access root@linux# setpriv --reuid=9999 --regid=9999 --clear-groups ls /mnt/untrusted_ro_fs/root ls: cannot open directory '/root': Permission denied

root@linux# ###(3b) unpriviledge process cat (run with uid=9999 and gid=9999) no read access root@linux# setpriv --reuid=9999 --regid=9999 --clear-groups cat /mnt/untrusted_ro_fs/root/file cat: /mtn/untrusted_ro_fs/root/file: Permission denied

root@linux# ###(4) file permission change fails on ro filesystem root@linux# chmod a+rx /mnt/untrusted_ro_fs/root/ chmod: changing permissions of '/mnt/untrusted_ro_fs/root/': Read-only file system

I seek answers how to accomplish above read access (3a + 3b). This are the pathways I have come up with. Ideally answers would either a) provide alternative solutions or b) elaborate on those provided:

  • a) "daemon-style privelege drop": opening file-descriptors as root and subsequently setuid inside the process.

  • b) "using FIFOs" which appears only to help with (3b)
    root@linux# mkfifo /access_to_root_file.fifo
    root@linux# chown root:9999 /access_to_root_file.fifo
    root@linux# chmod 0640 /access_to_root_file.fifo
    root@linux# cat /mnt/untrusted_ro_fs/root/file > /access_to_root_file.fifo & root@linux# setpriv --reuid=9999 --regid=9999 --clear-groups cat /access_to_root_file.fifo

  • c) "overlayfs"
    root@linux# mkdir /mnt/upper /mnt/work /mnt/merged
    root@linux# mount -t overlay overlay -o lowerdir=/mnt/untrusted_ro_fs,upperdir=/mnt/upper,workdir=/mnt/work /mnt/merged root@linux# chmod a+rx /mnt/merged/root root@linux# setpriv --reuid=9999 --regid=9999 --clear-groups ls /mnt/merged/root &>/dev/null && echo SUCCESS-ls
    SUCCESS
    root@linux# chmod a+rx /mnt/merged/root/file root@linux# setpriv --reuid=9999 --regid=9999 --clear-groups cat /mnt/merged/root/file &>/dev/null && echo SUCCESS-cat
    SUCCESS

  • d) "virtualization" (i.e. kvv + qemu) where the readonly access to blockdevice of untrusted filesystem is setup for the vm.

1 Answers1

1

The method that seems most natural to me is to create another view of the filesystem with different access rules, as in Mount device with r/w access to specific user. With bindfs:

mkdir -m 700 /mnt/permissive_view
chown 9999:9999 /mnt/permissive_view
bindfs -r -M 9999 /mnt/untrusted_ro_fs /mnt/permissive_view

Then have 9999 access files under /mnt/permissive_view.

The option -M 9999 causes user 9999 to see itself as the owner of all files. Depending on your exact use case, you may want different mappings, for example -u 9999 (causes all users to see 9999 as the owner) or --map=0/9999 (causes 9999 to be the apparenty owner of root-owned files only).

  • thank you for this suggestion, I am gald I asked the question, having overlooked this solution that is similar to overlayfs but in some way clearer. With bindfs I have to wonder though, is it possible to have a "thumb-rule" for bindfs being FUSE if this is a) "security" is FUSE already safer (not in kernel) or less rather less safe (added complexity) and b) is the general idead true that this solution comes at a cost of performance (user vs. kernel)? – humanityANDpeace Jul 05 '21 at 06:11
  • @humanityANDpeace FUSE filesystems tend to be safer since the most delicate parts run in user mode, and so the worst that can happen is a user mode crash or compromise rather than a kernel crash or compromise. Bindfs doesn't really involve delicate parts though. FUSE does cost performance, only you can tell whether it matters in your case. – Gilles 'SO- stop being evil' Jul 05 '21 at 07:40