On Tue, Mar 11, 2025 at 01:58:57PM -0700, Song Liu wrote:

On Tue, Mar 11, 2025 at 12:28 PM Mickaël Salaün [off-list ref] wrote:

quoted

On Tue, Mar 11, 2025 at 12:42:05AM +0000, Tingmao Wang wrote:

quoted

On 3/6/25 17:07, Amir Goldstein wrote:
[...]

quoted

quoted

--

For Mickaël,

Would you be on board with changing Landlock to use the new hooks as
mentioned above?  My thinking is that it shouldn't make any difference in
terms of security - Landlock permissions for e.g. creating/deleting files
are based on the parent, and in fact except for link and rename, the
hook_path_ functions in Landlock don't even use the dentry argument.  If
you're happy with the general direction of this, I can investigate further
and test it out etc.  This change might also reduce the impact of Landlock
on non-landlocked processes, if we avoid holding exclusive inode lock while
evaluating rules / traversing paths...? (Just a thought, not measured)

I think the filter for process/thread is usually faster than the filter for
file/path/subtree? Therefore, it is better for landlock to check the filter for
process/thread first. Did I miss/misunderstand something?

The main reason is because only sandboxed processes should be impacted
by Landlock.  Similarly, only the security policies restricting a
process impact this process.  Using 16 layers would only impact the
process that sandboxed itself (and BTW the impact of the number of
layers would be negligible).  There is not really process filters, only
pointers set or not in tasks' credentials.