Re: Landlock and O_PATH

On 22/02/2022 00:04, S.M Mukarram Nainar wrote:
>> That is correct, the current Landlock implementation relies on the LSM
>> path hooks, and some filesystem actions are not handled. See the warning
>> section in
>> https://docs.kernel.org/userspace-api/landlock.html#filesystem-flags
>> Opening a file or a directory with O_PATH cannot currently be denied
>> with Landlock and it is the same with AppArmor and Tomoyo. It may sound
>> scary but a file descriptor opened with O_PATH can only be used to refer
>> to a path (with *at syscalls), it does not give access to the underlying
>> file or directory content.
>>
>> You're right that it may be used as an oracle to find file or
>> directories, and this can also be done with syscalls such as chdir,
>> access or stat. The current goal of Landlock is to protect access to
>> data, which are in files, but it would be nice to also protect metadata
>> such as path existence.
> 
> Right, I see. That makes sense.
> 
>> I plan to fill this gap with new versions of Landlock, but I'll have to
>> patch the existing LSM framework.
> 
> Looking forward to this! I think it may be useful (considering Hyrum's
> law) to document what is planned to be blocked in the future so that
> application developers can use landlock safely now without worrying
> about incompatibilities. It would kind of suck if applications would
> break on newer kernels. That's my two cents anyway, I know you must
> already be very busy.

Landlock is designed to be backward and forward compatible just to avoid 
this kind of issue. An application being restricted with a set of access 
right will not automatically get new ones with a newer kernel: action 
handling is explicit (see ruleset's handled_access_fs). I'm extending 
the documentation with this specific subject: 
https://lore.kernel.org/r/[email protected]

> 
> Thanks,
> Mukarram