statfs(2) control

[gnoack]

statfs(2) lets callers probe for the existence of files, and retrieve information about the file system. We might want to restrict that.

• There is already an existing LSM hook for that.
• Having that access right should probably also enable the use of some related IOCTLs which are closely related, like FIGETBSZ and maybe FIBMAP and FS_IOC_FIEMAP.

[l0kod]

This is related to #11, but I'm wondering if it would be a good idea to tie statfs(2) to LANDLOCK_ACCESS_FS_READ_METADATA. :thinking:

About the ability to probe for file existence, the right approach would be #9 .

What are the legitimate use cases to use statfs(2)?

It looks like it is a tool for compatibility and performance to better interact with the running system.

What is the threat with statfs(2)?

statfs(2) enables to get metadata about filesystems, not direct data. It is a way to create cover channels, like so many other ways though. Do we really need to restrict its use? The answer to this question could impact #4 .

How to identify filesystems?

If we need to control this interface, should we use a landlock_path_beneath_attr or a new rule type to scope to a mount point or a block device instead of a file hierarchy? This new rule could contain almost the same fields but with a different semantic (e.g. not parent_fd but mount_fd or dev_fd instead).