Re: Landlock and O_PATH

On 25/02/2022 10:22, Mickaël Salaün wrote:
> 
> 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 

FYI, I added new tests to make sure the O_PATH handling will never 
change: https://lore.kernel.org/r/[email protected]


> Regards,
>   Mickaël