> On Jul 11, 2025, at 2:36 AM, Christian Brauner <brauner@xxxxxxxxxx> wrote: [...] >>> >> To make sure I understand the comment. By “new mount api”, do you mean >> the code path under do_new_mount()? > > fsopen() > fsconfig() > fsmount() > open_tree() > open_tree_attr() > move_mount() > statmount() > listmount() > > I think that's all. Thanks for the clarification and pointer! > >> >>> My recommendation is make a list of all the currently supported >>> security_*() hooks in the mount code (I certainly don't have them in my >>> head). Figure out what each of them allow to mediate effectively and how >>> the callchains are related. >>> >>> Then make a proposal how to replace them with something that a) doesn't >>> cause regressions which is probably something that the LSMs care about >>> and b) that covers the new mount API sufficiently to be properly >>> mediated. >>> >>> I'll happily review proposals. Fwiw, I'm pretty sure that this is >>> something that Mickael is interested in as well. >> >> So we will consider a proper redesign of LSM hooks for mount syscalls, >> but we do not want incremental improvements like this one. Do I get >> the direction right? > > If incremental is workable then I think so yes. But it would be great to > get a consistent picture of what people want/need. In short term, we would like a way to get struct path of dev_name for bind mount. AFAICT, there are a few options: 1. Introduce bpf_kern_path kfunc. 2. Add new hook(s), such as [1]. 3. Something like this patch. [1] https://lore.kernel.org/linux-security-module/20250110021008.2704246-1-enlightened@xxxxxxxxxxxx/ Do you think we can ship one of them? Thanks, Song
