Re: R/O protection for lower level dirs

Hi,

I have a working tree that implements this feature. It's implemented in 
a flag named LANDLOCK_ADD_RULE_NO_INHERIT.

It's the successor to the first patch I submitted here:

v1: 
https://lore.kernel.org/linux-security-module/[email protected]/T/#t

The above first implemented version patch implemented the flag without 
any parent directory protections.

Both the old version of the patch and my new version build on Tingmao 
Wang's patch to add LANDLOCK_ADD_RULE_QUIET, which helpfully added a 
rule with similar flag propagation logic.

v3: 
https://lore.kernel.org/linux-security-module/[email protected]/

I still have to break it out into a patch and implement the kunit and 
flesh out the selftests, but you can find my new implementation and 
build it yourself here: 
https://github.com/RazeLighter777/linux-landlock-no-inherit

And you can see the relevant recent discussion on this issue: 
https://github.com/landlock-lsm/linux/issues/28

There is a newer version of Tingmao Wang's patch (v4) that I will rebase 
off soon, but it mostly concerned adding new tests so it shouldn't be 
difficult.

Rules tagged with LANDLOCK_ADD_RULE_NO_INHERIT attribute have the 
following properties:

1.  Access grants from a rule on a parent inode on the same 
mountpoint will not be propagated downward to child inodes. So a grant 
on /a = rw and /a/b = ro + LANDLOCK_ADD_RULE_NO_INHERIT will not grant 
/a/b write permissions.

2. Refer operations in the direct parent path of the inode (up to the 
mountpoint root) will be blocked if they operate directly on said path. 
So if /a/b/c/d = ro + LANDLOCK_ADD_RULE_NO_INHERIT, moving a,b,c or d, 
creating links to these files, renaming them, or removing them will be 
disallowed. This prevents breaking the file topology and preventing 
sandbox restart attacks.

3. LANDLOCK_ADD_RULE_NO_INHERIT propagates to child layers and is merged 
correctly across domains.

The use cases for this patch could be:

1. Granting access to /home/user, but restricting sensitive directories 
like /home/user/.ssh

2. More fine grained restrictions on USB or other devices in /dev. So 
you could a program to allow /dev/usb, but forbid a specific device 
/dev/usb/hiddev3 for instance.

Here's a demo of the patch. LL_FS_RO_NO_INHERIT is a landlock-sandboxer 
environment variable I added in which just creates an ro + 
LANDLOCK_ADD_RULE_NO_INHERIT rule on an inode.

Demo:

~ # LL_FS_RO="" LL_FS_RW="/" LL_FS_RO_NO_INHERIT="/a/b/c" 
landlock-sandboxer sh
Executing the sandboxed command...
~ # ls
a      dev    init   root   sys    tmp
bin    etc    proc   sbin   tests  usr
~ # rm -rf a/
rm: can't remove 'a/b/c': Permission denied
~ # mv a b
mv: can't rename 'a': Permission denied
~ # cd a/
/a # ls
b
/a # mv b bad
mv: can't rename 'b': Permission denied
/a # ln b bad
ln: bad: Operation not permitted
/a # ln bad b
ln: bad: No such file or directory
/a # rm -rf b
rm: can't remove 'b/c': Permission denied
/a # cd b
/a/b # ls
c
/a/b # rm -rf c
rm: can't remove 'c': Permission denied
/a/b # mv c bad
mv: can't rename 'c': Permission denied
/a/b # touch c/bad
touch: c/bad: Permission denied
/a/b # cd c
/a/b/c # ls
/a/b/c # ls -al
total 0
drwxr-xr-x    2 0        0               40 Nov  9 14:46 .
drwxr-xr-x    3 0        0               60 Nov  9 14:46 ..
/a/b/c # mount --bind /tmp .
mount: permission denied (are you root?)
/a/b/c # cd ..
/a/b # touch fi
/a/b # ls
c   fi
/a/b # mkdir good
/a/b # touch good/test
/a/b # rm -rf good/
/a/b #

Some things I'd like to hear feedback on:

1. Should parent directory refer operation restrictions apply on parent 
directories above the mountpoint? Currently they only propagate up to 
the mountpoint, so you if you had /a/b/c = ro + 
LANDLOCK_ADD_RULE_NO_INHERIT and / = rw, if /a/b was on a different 
mountpoint than /, you could still move /a to /unrelated for instance. 
This wouldn't be difficult to fix, but would add some complexity.

2. Potential for extension to other scopes? It's unclear how this flag 
could be useful for other cases such as network and signal restrictions, 
but if somebody can think of something interesting it might be worth a look.

3. Any edge cases that should be tested for that I might have missed / 
that need addressing.

I'd also love to hear feedback from Nicholas and see their work and 
incorporate any lessons learned from them.

Kind Regards,

Justin Suess