On Thu, Sep 28, 2023 at 6:07 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Tue, 19 Sept 2023 at 18:48, Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > Ideally we avoid multiple capable(CAP_SYS_ADMIN) calls by only doing it > > > once and saving the return value. capable() call's aren't that cheap. > > > > Agreed. The capability check doesn't do any subject/object > > comparisons so calling it for each mount is overkill. However, I > > would think we would want the LSM hook called from inside the loop as > > that could involve a subject (@current) and object (individual mount > > point) comparison. My apologies, I was traveling and while I was quickly checking my email each day this message was lost. I'm very sorry for the delay in responding. > The security_sb_statfs() one? Yes. > Should a single failure result in a complete failure? My opinion is that it should only result in the failure of that listing/stat'ing that particular mount; if other mounts are allowed to be queried than the operation should be allowed to continue. > Why is it not enough to check permission on the parent? Each mount has the potential to have a unique security identify in the context of the LSM, and since the LSM access controls are generally intended to support a subject-verb-object access control policy we need to examine the subject and object together (the subject here is @current, the object is the individual mount, and the verb is the stat/list operation). Does that make sense? I'm looking at the v3 patchset right now, I've got some small nits, but I'll add those to that thread. -- paul-moore.com
