Re: [RFC PATCH v15 18/21] ipe: enable support for fs-verity as a trust provider

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 3/18/2024 1:08 AM, Roberto Sassu wrote:
On Sun, 2024-03-17 at 22:17 -0700, Eric Biggers wrote:
On Fri, Mar 15, 2024 at 08:35:48PM -0700, Fan Wu wrote:
+config IPE_PROP_FS_VERITY
+	bool "Enable property for fs-verity files"
+	depends on FS_VERITY && FS_VERITY_BUILTIN_SIGNATURES
+	help
+	  This option enables the usage of properties "fsverity_signature"
+	  and "fsverity_digest". These properties evaluate to TRUE when
+	  a file is fsverity enabled and with a signed digest

Again: why would anyone care if there is a signature, if that signature is not
checked.

I think you meant to write something like: "when a file is fsverity enabled and
has a valid builtin signature whose signing cert is in the .fs-verity keyring".

I was also thinking the same. I didn't follow the recent development
closely, but unless IPE locks somehow the .fs-verity keyring, the
property you suggested would not be immutable. Meaning that someone can
add/remove a key in that keyring, making the property true or false.

Roberto

Yes, the .fs-verity keyring's mutability could affect the property's immutability. However, we are not planing to "lock" the keyrings, but we would like to use policies languages to express what certificate can be trusted.

For example, we can have a rule like this:

#Certificate declaration
CERTIFICATE=MyCertificate CertThumbprint=DummyThumbprint
op=EXECUTE fsverity_signature=MyCertificate action=ALLOW

This will be our immediate next work after the initial version is accepted.

-Fan





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux