Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v2 00/10] allow unprivileged overlay mounts
To:     Miklos Szeredi <mszeredi@redhat.com>,
        "Eric W . Biederman" <ebiederm@xmission.com>
Cc:     linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        John Johansen <john.johansen@canonical.com>
References: <20201207163255.564116-1-mszeredi@redhat.com>
From:   Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Message-ID: <1725e01a-4d4d-aecb-bad6-54aa220b4cd2@i-love.sakura.ne.jp>
Date:   Tue, 8 Dec 2020 19:27:13 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <20201207163255.564116-1-mszeredi@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.