On Tue 11-03-25 00:42:05, Tingmao Wang wrote: > On 3/6/25 17:07, Amir Goldstein wrote: > [...] > > > > w.r.t sharing infrastructure with fanotify, I only looked briefly at > > your patches > > and I have only a vague familiarity with landlock, so I cannot yet form an > > opinion whether this is a good idea, but I wanted to give you a few more > > data points about fanotify that seem relevant. > > > > 1. There is already some intersection of fanotify and audit lsm via the > > fanotify_response_info_audit_rule extension for permission > > events, so it's kind of a precedent of using fanotify to aid an lsm > > > > 2. See this fan_pre_modify-wip branch [1] and specifically commit > > "fanotify: introduce directory entry pre-modify permission events" > > I do have an intention to add create/delete/rename permission events. > > Note that the new fsnotify hooks are added in to do_ vfs helpers, not very > > far from the security_path_ lsm hooks, but not exactly in the same place > > because we want to fsnotify hooks to be before taking vfs locks, to allow > > listener to write to filesystem from event context. > > There are different semantics than just ALLOW/DENY that you need, > > therefore, only if we move the security_path_ hooks outside the > > vfs locks, our use cases could use the same hooks > > Hi Amir, > > (this is a slightly long message - feel free to respond at your convenience, > thank you in advance!) > > Thanks a lot for mentioning this branch, and for the explanation! I've had a > look and realized that the changes you have there will be very useful for > this patch, and in fact, I've already tried a worse attempt of this (not > included in this patch series yet) to create some security_pathname_ hooks > that takes the parent struct path + last name as char*, that will be called > before locking the parent. (We can't have an unprivileged supervisor cause > a directory to be locked indefinitely, which will also block users outside > of the landlock domain) Well, but if you call the hook before locking the parent isn't your hook prone to TOCTOU races? I mean you call the hook do your stuff in it and then before the parent is locked, the whole directory hierarchy can get reorganized (from another process) without you knowing... So I'm not sure which guarantees you can provide for such hooks. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
