Because of the way path-based LSM hooks work, it is not possible to control some actions such as chdir, which may enable a sandboxed process to infer file names. It would be great to be able to control path walking and then get a complete control on file access with a new LANDLOCK_ACCESS_FS_WALK right.
The LANDLOCK_ACCESS_FS_REFER right (and LANDLOCK_ACCESS_FS_{READ,WRITE}_{FILE,DIR}) would then still allow to open files or directories with O_PATH (which is currently always allowed).
Adding a new LSM hook in filename_lookup() should enable to tie a path to an inode, and then leverage most inode-based LSM hooks. For this to be efficient, we need to implement a small cache per path walk, more generic than an initial approach.
This approach should also significantly improve performance of Landlock's file access control.
Because of the way path-based LSM hooks work, it is not possible to control some actions such as
chdir
, which may enable a sandboxed process to infer file names. It would be great to be able to control path walking and then get a complete control on file access with a newLANDLOCK_ACCESS_FS_WALK
right.The
LANDLOCK_ACCESS_FS_REFER
right (andLANDLOCK_ACCESS_FS_{READ,WRITE}_{FILE,DIR}
) would then still allow to open files or directories withO_PATH
(which is currently always allowed).Adding a new LSM hook in
filename_lookup()
should enable to tie a path to an inode, and then leverage most inode-based LSM hooks. For this to be efficient, we need to implement a small cache per path walk, more generic than an initial approach.This approach should also significantly improve performance of Landlock's file access control.
See https://lore.kernel.org/all/20230901.OhT2suinooGh@digikod.net/