On 12/8/20 2:27 AM, Tetsuo Handa wrote: > On 2020/12/08 1:32, Miklos Szeredi wrote: >> A general observation is that overlayfs does not call security_path_*() >> hooks on the underlying fs. I don't see this as a problem, because a >> simple bind mount done inside a private mount namespace also defeats the >> path based security checks. Maybe I'm missing something here, so I'm >> interested in comments from AppArmor and Tomoyo developers. > > Regarding TOMOYO, I don't want overlayfs to call security_path_*() hooks on the > underlying fs, but the reason is different. It is not because a simple bind mount > done inside a private mount namespace defeats the path based security checks. > TOMOYO does want to check what device/filesystem is mounted on which location. But > currently TOMOYO is failing to check it due to fsopen()/fsmount()/move_mount() API. > Regardless of TOMOYO's approach I would say that overlays should call the security_path_*() hooks, making it possible for an LSM to do something based off of them when needed. The current state of private mounts with regard to path based mediation is broken. I just haven't had time to try and come up with an acceptable fix for it. overlayfs is actually broken under apparmor mediation, and accesses to the lower layer end up getting denied but there is no way to properly allow them. So policy that hits this needs a flag set that allows for it in a very hacky way (its on the list of things to fix). Path based mediation has to carefully control mounts otherwise policy can be circumvented as Miklos rightly points out. Ideally path based LSM wouldn't allow you to do the simple bind mount inside a private mount namespace (at least not unless policy allowed for it). AppArmor does mediate the mount hooks and bind mounts in a private mount namespace (if they go through the LSM mount hooks) will be denied. Again the problem is how to allow them, and this is broken.
