Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Date:   Mon, 11 Dec 2023 09:36:21 -0600
From:   Seth Forshee <sforshee@kernel.org>
To:     Roberto Sassu <roberto.sassu@huaweicloud.com>
Cc:     Christian Brauner <brauner@kernel.org>,
        Amir Goldstein <amir73il@gmail.com>, miklos@szeredi.hu,
        linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org,
        zohar@linux.ibm.com, paul@paul-moore.com, stefanb@linux.ibm.com,
        jlayton@kernel.org, linux-integrity@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        linux-fsdevel@vger.kernel.org,
        Roberto Sassu <roberto.sassu@huawei.com>
Subject: Re: [RFC][PATCH] overlayfs: Redirect xattr ops on security.evm to
 security.evm_overlayfs
Message-ID: <ZXcsdf6BzszwZc9h@do-x1extreme>
References: <20231208172308.2876481-1-roberto.sassu@huaweicloud.com>
 <CAOQ4uxivpZ+u0A5kE962XST37-ey2Tv9EtddnZQhk3ohRkcQTw@mail.gmail.com>
 <20231208-tauziehen-zerfetzt-026e7ee800a0@brauner>
 <c95b24f27021052209ec6911d2b7e7b20e410f43.camel@huaweicloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c95b24f27021052209ec6911d2b7e7b20e410f43.camel@huaweicloud.com>
Precedence: bulk

On Mon, Dec 11, 2023 at 03:56:06PM +0100, Roberto Sassu wrote:
> Ok, I will try.
> 
> I explain first how EVM works in general, and then why EVM does not
> work with overlayfs.
> 
> EVM gets called before there is a set/removexattr operation, and after,
> if that operation is successful. Before the set/removexattr operation
> EVM calculates the HMAC on current inode metadata (i_ino, i_generation,
> i_uid, i_gid, i_mode, POSIX ACLs, protected xattrs). Finally, it
> compares the calculated HMAC with the one in security.evm.
> 
> If the verification and the set/removexattr operation are successful,
> EVM calculates again the HMAC (in the post hooks) based on the updated
> inode metadata, and sets security.evm with the new HMAC.
> 
> The problem is the combination of: overlayfs inodes have different
> metadata than the lower/upper inodes; overlayfs calls the VFS to
> set/remove xattrs.

I don't know all of the inner workings of overlayfs in detail, but is it
not true that whatever metadata an overlayfs mount presents for a given
inode is stored in the lower and/or upper filesystem inodes? If the
metadata for those inodes is verified with EVM, why is it also necessary
to verify the metadata at the overlayfs level? If some overlayfs
metadata is currently omitted from the checks on the lower/upper inodes,
is there any reason EVM couldn't start including that its checksums?
Granted that there could be some backwards compatibility issues, but
maybe inclusion of the overlayfs metadata could be opt-in.

Thanks,
Seth