[PATCH v2 00/10] allow unprivileged overlay mounts

[John Johansen]

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.