Hi Amir! On Sun 14-04-19 19:04:14, Amir Goldstein wrote: > I started to look at directory pre-modification "permission" hooks > that were discussed on last year's LSFMM: > https://lwn.net/Articles/755277/ > > The two existing fanotify_perm() hooks are called > from security_file_permission() and security_file_open() > and depend on build time CONFIG_SECURITY. > If you look at how the fsnotify_perm() hooks are planted inside the > generic security hooks, one might wonder, why are fanotify permission > hooks getting a special treatment and are not registering as LSM hooks? > > One benefit from an fanotify LSM, besides more generic code, would be > that fanotify permission hooks could be disabled with boot parameters. > > I only bring this up because security hooks seems like the most natural > place to add pre-modify fanotify events for the purpose of maintaining > a filesystem change journal. It would be ugly to spray more fsnotify hooks > inside security hooks instead of registering an fanotify LSM, but maybe > there are downsides of registering fanotify as LSM that I am not aware of? I kind of like the idea of generating fanotify permission events from special LSM hooks. I'm not so sure about directory pre-modification hooks. Given the amount of problems we face with applications using fanotify permission events and deadlocking the system, I'm not very fond of expanding that API... AFAIU you want to use such hooks for recording (and persisting) that some change is going to happen and provide crash-consistency guarantees for such journal? > Another observation relates to the security_path_ hooks. > Let's take rename as an example. > LSM could implement security_path_rename() and/or security_inode_rename() > hooks and rename syscalls will end up calling both hooks. > The security_path_ hooks are more attractive for fanotify, because the path > information could be used to setup pre-modification permission mask on > mount marks and not only on filesystem/inode marks. > > One problem with security_path_ hooks is that they require an extra > build time CONFIG_SECURITY_PATH. > Another problem is that they seem to be bypassed by several subsystems. > cachefiles, ecryptfs, overlayfs and nfsd all call the vfs_rename() helper, but > only cachefiles bothers to call the security_path_rename() hook. > This is of course true for all other security_path_ hooks. > I think that is something that requires fixing regardless of the fanotify pre > modification hooks. I wonder if tomoyo and apparmor developers > (LSM that implement security_path_ hooks) are aware of those missing > hooks? > > Would love to get feedback about whether or not fanotify LSM sounds > like a good or bad idea and about the security_path_ hooks questions. I don't have strong opinion on using security_path_ hooks. I guess if they're not used everywhere then it's just easier to avoid them. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
