Received-SPF: pass (google.com: domain of linux-kernel+bounces-88459-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <e6f263b25061651e948a881d36bfdff17cfaf1b0.camel@huaweicloud.com>
Subject: Re: [PATCH v2 14/25] evm: add support for fscaps security hooks
From: Roberto Sassu <roberto.sassu@huaweicloud.com>
To: Christian Brauner <brauner@kernel.org>
Cc: "Seth Forshee (DigitalOcean)" <sforshee@kernel.org>, Serge Hallyn
 <serge@hallyn.com>, Paul Moore <paul@paul-moore.com>, Eric Paris
 <eparis@redhat.com>, James Morris <jmorris@namei.org>, Alexander Viro
 <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>, Stephen Smalley
 <stephen.smalley.work@gmail.com>, Ondrej Mosnacek <omosnace@redhat.com>, 
 Casey Schaufler <casey@schaufler-ca.com>, Mimi Zohar <zohar@linux.ibm.com>,
 Roberto Sassu <roberto.sassu@huawei.com>,  Dmitry Kasatkin
 <dmitry.kasatkin@gmail.com>, Eric Snowberg <eric.snowberg@oracle.com>,
 "Matthew Wilcox (Oracle)" <willy@infradead.org>, Jonathan Corbet
 <corbet@lwn.net>, Miklos Szeredi <miklos@szeredi.hu>, Amir Goldstein
 <amir73il@gmail.com>,  linux-kernel@vger.kernel.org,
 linux-fsdevel@vger.kernel.org,  linux-security-module@vger.kernel.org,
 audit@vger.kernel.org,  selinux@vger.kernel.org,
 linux-integrity@vger.kernel.org,  linux-doc@vger.kernel.org,
 linux-unionfs@vger.kernel.org
Date: Fri, 01 Mar 2024 14:19:11 +0100
In-Reply-To: <20240301-zucht-umfeld-9a923a7d070a@brauner>
References: <20240221-idmap-fscap-refactor-v2-0-3039364623bd@kernel.org>
	 <20240221-idmap-fscap-refactor-v2-14-3039364623bd@kernel.org>
	 <15a69385b49c4f8626f082bc9b957132388414fb.camel@huaweicloud.com>
	 <20240301-zucht-umfeld-9a923a7d070a@brauner>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu2 
Precedence: bulk
MIME-Version: 1.0

On Fri, 2024-03-01 at 13:54 +0100, Christian Brauner wrote:
> On Fri, Mar 01, 2024 at 10:19:13AM +0100, Roberto Sassu wrote:
> > On Wed, 2024-02-21 at 15:24 -0600, Seth Forshee (DigitalOcean) wrote:
> > > Support the new fscaps security hooks by converting the vfs_caps to r=
aw
> > > xattr data and then handling them the same as other xattrs.
> >=20
> > Hi Seth
> >=20
> > I started looking at this patch set.
> >=20
> > The first question I have is if you are also going to update libcap
> > (and also tar, I guess), since both deal with the raw xattr.
> >=20
> > From IMA/EVM perspective (Mimi will add on that), I guess it is
> > important that files with a signature/HMAC continue to be accessible
> > after applying this patch set.
> >=20
> > Looking at the code, it seems the case (if I understood correctly,
> > vfs_getxattr_alloc() is still allowed).
> >=20
> > To be sure that everything works, it would be really nice if you could
> > also extend our test suite:
> >=20
> > https://github.com/mimizohar/ima-evm-utils/blob/next-testing/tests/port=
able_signatures.test
> >=20
> > and
> >=20
> > https://github.com/mimizohar/ima-evm-utils/blob/next-testing/tests/evm_=
hmac.test
> >=20
> >=20
> > The first test we would need to extend is check_cp_preserve_xattrs,
> > which basically does a cp -a. We would need to set fscaps in the
> > origin, copy to the destination, and see if the latter is accessible.
> >=20
> > I would also extend:
> >=20
> > check_tar_extract_xattrs_different_owner
> > check_tar_extract_xattrs_same_owner
> > check_metadata_change
> > check_evm_revalidate
> > check_evm_portable_sig_ima_appraisal
> > check_evm_portable_sig_ima_measurement_list
> >=20
> > It should not be too complicated. The purpose would be to exercise your
> > code below.
> >=20
> >=20
> > Regarding the second test, we would need to extend just check_evm_hmac.
> >=20
> >=20
> > Just realized, before extending the tests, it would be necessary to
> > modify also evmctl.c, to retrieve fscaps through the new interfaces,
> > and to let users provide custom fscaps the HMAC or portable signature
> > is calculated on.
>=20
> While request for tests are obviously fine they should be added by the
> respective experts for IMA/EVM in this case. I don't think it's
> appropriate to expect Seth to do that especially because you seem to
> imply that you currently don't have any tests for fscaps at all. We're
> always happy to test things and if that'd be adding new IMA/EVM specific
> features than it would be something to discuss but really we're
> refactoring so the fact that you don't have tests we can run is not the
> fault of this patchset and IMA/EVM is just a small portion of it.=20

Hi Christian

I have seen this policy of adding tests in other subsystems (eBPF),
which in my opinion makes sense, since you want anyway to check that
you didn't break existing code.

And yes, I agree that we should have better tests, and a better
workflow (we are working on improving it).

In this particular case, I was not asking to write a test from scratch,
that should not be difficult per se, but adding additional commands.

If I got it correctly, even if current tests for fscaps would have
existed, they would not work anyway, since they would have been based
on getting/setting the raw xattrs (as far as I know, at least for tar).

Happy to try adding the tests, would appreciate your help to review if
the tests are done in the correct way.

Thanks

Roberto