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 <mic@xxxxxxxxxxx> wrote: > > > > On Tue, Mar 11, 2025 at 12:42:05AM +0000, Tingmao Wang wrote: > > > On 3/6/25 17:07, Amir Goldstein wrote: > > > [...] > > > -- > > > > > > 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.
