Re: Landlock and O_PATH

On 24/02/2022 22:11, S.M Mukarram Nainar wrote:
>> Correct, a given Landlock flag/command/attribute will not change
>> behavior over time, as (in theory) all Linux interfaces. If a flag is
>> not enough, extensible structs used by the Landlock syscalls can be
>> used:
>> https://lpc.events/event/7/contributions/657/attachments/639/1159/extensible_syscalls.pdf
> 
> That makes sense. One (hopefully) final question: What is Landlock's
> policy around future changes in the kernel? Taking the earlier example,
> O_PATH was apparently added in Linux 2.6.39. If Landlock had existed
> prior to that, and LANDLOCK_ACCESS_FS_WALK as well, would the flag have
> been extended to cover that usecase? To be maybe more clear, I'm
> wondering if I can trust Landlock policies to always restrict a given
> action, irrespective of what new ways to do it may be introduced in
> the future?

Landlock uses the LSM framework, which defines a set of hooks according 
to access semantic. O_PATH and chdir is not currently supported for 
path-based LSMs but it is handled for inode-based LSMs such as SELinux 
and Smack. The underlying idea of these LSM hooks is that they should be 
used for every new Linux interfaces doing similar things, so that LSMs 
don't have to be updated specifically for new UAPI change. So yes, you 
can trust Landlock policies to always restrict a given action. If, for 
whatever reason, it happens that a new Linux interface is added without 
the appropriate LSM hook or if Landlock doesn't support it somehow, then 
we can define a new Landlock access right defining this new action. 
There is a bunch of tests covering the several actions (handled or not) 
and they must pass for every kernel releases: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/landlock

Regards,
  Mickaël