RFC: Make it practical to ship EVM signatures

A reasonable configuration is to use IMA to appraise a subset of files (based on user, security label or other features supported by IMA) but to also want to use EVM to validate not only the state of the IMA hash but also additional metadata on the file. Right now this is only possible if a symmetric key has been loaded, which may not be desirable in all cases (eg, one where EVM digital signatures are shipped to end systems rather than EVM HMACs being generated locally).

Add an
additional "require_evm" keyword to the IMA policy language in order to permit the local admin to indicate that they wish EVM validation to occur even if no symmetric key has been loaded.

Signed-off-by Matthew Garrett <[email protected]>

---
 Documentation/ABI/testing/ima_policy  |  3 ++-
 include/linux/evm.h                   |  6 ++++--
 security/integrity/evm/evm_main.c     |  6 ++++--
 security/integrity/ima/ima_appraise.c | 11 ++++++++++-
 security/integrity/ima/ima_policy.c   | 12 +++++++++++-
 security/integrity/integrity.h        |  3 ++-
 6 files changed, 33 insertions(+), 8 deletions(-)

Documentation/ABI/testing/ima_policy +2 -1

index 5dc9eed035fb..ea2703c847f6 100644
@@ -23,7 +23,8 @@ Description:
 				[euid=] [fowner=]]
 			lsm:	[[subj_user=] [subj_role=] [subj_type=]
 				 [obj_user=] [obj_role=] [obj_type=]]
-			option:	[[appraise_type=]] [permit_directio]
+			option:	[[appraise_type=] [permit_directio]
+			         [require_evm]]
 
 		base: 	func:= [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK][MODULE_CHECK]
 				[FIRMWARE_CHECK]

include/linux/evm.h +4 -2

index 35ed9a8a403a..7661f3085942 100644
@@ -19,7 +19,8 @@ extern enum integrity_status evm_verifyxattr(struct dentry *dentry,
 					     const char *xattr_name,
 					     void *xattr_value,
 					     size_t xattr_value_len,
-					     struct integrity_iint_cache *iint);
+					     struct integrity_iint_cache *iint,
+					     bool force);
 extern int evm_inode_setattr(struct dentry *dentry, struct iattr *attr);
 extern void evm_inode_post_setattr(struct dentry *dentry, int ia_valid);
 extern int evm_inode_setxattr(struct dentry *dentry, const char *name,

@@ -54,7 +55,8 @@ static inline enum integrity_status evm_verifyxattr(struct dentry *dentry,
 						    const char *xattr_name,
 						    void *xattr_value,
 						    size_t xattr_value_len,
-					struct integrity_iint_cache *iint)
+					      struct integrity_iint_cache *iint,
+						    bool force)
 {
 	return INTEGRITY_UNKNOWN;
 }

security/integrity/evm/evm_main.c +4 -2

index 063d38aef64e..44e4f4fda965 100644
@@ -223,6 +223,7 @@ static int evm_protected_xattr(const char *req_xattr_name)
  * @xattr_name: requested xattr
  * @xattr_value: requested xattr value
  * @xattr_value_len: requested xattr value length
+ * @force: force verification even if no EVM symmetric key is loaded
  *
  * Calculate the HMAC for the given dentry and verify it against the stored
  * security.evm xattr. For performance, use the xattr value and length

@@ -236,9 +237,10 @@ static int evm_protected_xattr(const char *req_xattr_name)
 enum integrity_status evm_verifyxattr(struct dentry *dentry,
 				      const char *xattr_name,
 				      void *xattr_value, size_t xattr_value_len,
-				      struct integrity_iint_cache *iint)
+				      struct integrity_iint_cache *iint,
+				      bool force)
 {
-	if (!evm_initialized || !evm_protected_xattr(xattr_name))
+	if ((!evm_initialized || !evm_protected_xattr(xattr_name)) && !force)
 		return INTEGRITY_UNKNOWN;
 
 	if (!iint) {

security/integrity/ima/ima_appraise.c +10 -1

index edb82e722a0d..9df1148f17cc 100644
@@ -217,6 +217,7 @@ int ima_appraise_measurement(enum ima_hooks func,
 	struct inode *inode = d_backing_inode(dentry);
 	enum integrity_status status = INTEGRITY_UNKNOWN;
 	int rc = xattr_len, hash_start = 0;
+	bool evm_force = false;
 
 	if (!(inode->i_opflags & IOP_XATTR))
 		return INTEGRITY_UNKNOWN;

@@ -236,7 +237,15 @@ int ima_appraise_measurement(enum ima_hooks func,
 		goto out;
 	}
 
-	status = evm_verifyxattr(dentry, XATTR_NAME_IMA, xattr_value, rc, iint);
+	/*
+	 * Check if policy specifies that we should perform EVM
+	 * validation even in the absence of an EVM symmetric key
+	 */
+	if (iint->flags & IMA_EVM_REQUIRED)
+		evm_force = true;
+
+	status = evm_verifyxattr(dentry, XATTR_NAME_IMA, xattr_value, rc, iint,
+				 evm_force);
 	if ((status != INTEGRITY_PASS) && (status != INTEGRITY_UNKNOWN)) {
 		if ((status == INTEGRITY_NOLABEL)
 		    || (status == INTEGRITY_NOXATTRS))

security/integrity/ima/ima_policy.c +11 -1

index a6e14c532627..db4a0c968e00 100644
@@ -531,7 +531,7 @@ enum {
 	Opt_uid_gt, Opt_euid_gt, Opt_fowner_gt,
 	Opt_uid_lt, Opt_euid_lt, Opt_fowner_lt,
 	Opt_appraise_type, Opt_permit_directio,
-	Opt_pcr
+	Opt_pcr, Opt_require_evm,
 };
 
 static match_table_t policy_tokens = {

@@ -562,6 +562,7 @@ static match_table_t policy_tokens = {
 	{Opt_appraise_type, "appraise_type=%s"},
 	{Opt_permit_directio, "permit_directio"},
 	{Opt_pcr, "pcr=%s"},
+	{Opt_require_evm, "require_evm"},
 	{Opt_err, NULL}
 };
 

@@ -876,6 +877,13 @@ static int ima_parse_rule(char *rule, struct ima_rule_entry *entry)
 			else
 				entry->flags |= IMA_PCR;
 
+			break;
+		case Opt_require_evm:
+			if (entry->action != APPRAISE) {
+				result = -EINVAL;
+				break;
+			}
+			entry->flags |= IMA_EVM_REQUIRED;
 			break;
 		case Opt_err:
 			ima_log_string(ab, "UNKNOWN", p);

@@ -1142,6 +1150,8 @@ int ima_policy_show(struct seq_file *m, void *v)
 			}
 		}
 	}
+	if (entry->flags & IMA_EVM_REQUIRED)
+		seq_puts(m, "require_evm ");
 	if (entry->flags & IMA_DIGSIG_REQUIRED)
 		seq_puts(m, "appraise_type=imasig ");
 	if (entry->flags & IMA_PERMIT_DIRECTIO)

security/integrity/integrity.h +2 -1

index 45ba0e4501d6..2fa0d7bc55fb 100644
@@ -28,11 +28,12 @@
 
 /* iint cache flags */
 #define IMA_ACTION_FLAGS	0xff000000
-#define IMA_ACTION_RULE_FLAGS	0x06000000
+#define IMA_ACTION_RULE_FLAGS	0x16000000
 #define IMA_DIGSIG		0x01000000
 #define IMA_DIGSIG_REQUIRED	0x02000000
 #define IMA_PERMIT_DIRECTIO	0x04000000
 #define IMA_NEW_FILE		0x08000000
+#define IMA_EVM_REQUIRED	0x10000000
 
 #define IMA_DO_MASK		(IMA_MEASURE | IMA_APPRAISE | IMA_AUDIT | \
 				 IMA_APPRAISE_SUBMASK)

Quoted 7 lines · Matthew Garrett

A reasonable configuration is to use IMA to appraise a subset of files (based on user, security label or other features supported by IMA) but to also want to use EVM to validate not only the state of the IMA hash but also additional metadata on the file. Right now this is only possible if a symmetric key has been loaded, which may not be desirable in all cases (eg, one where EVM digital signatures are shipped to end systems rather than EVM HMACs being generated locally).

Commit 26ddabfe96bb "evm: enable EVM when X509 certificate is loaded" already allows EVM to be enabled without loading a symmetric key.

Quoted 9 lines · Mimi Zohar

Quoted 7 lines · Matthew Garrett

A reasonable configuration is to use IMA to appraise a subset of files (based on user, security label or other features supported by IMA) but to also want to use EVM to validate not only the state of the IMA hash but also additional metadata on the file. Right now this is only possible if a symmetric key has been loaded, which may not be desirable in all cases (eg, one where EVM digital signatures are shipped to end systems rather than EVM HMACs being generated locally).

Quoted 2 lines

Commit 26ddabfe96bb "evm: enable EVM when X509 certificate is loaded" already allows EVM to be enabled without loading a symmetric key.

This only seems to be set if CONFIG_EVM_LOAD_X509 is set. Should there be some sort of callback to set this if a key is loaded onto the evm keyring at runtime?

These are basically untested, but I'd like to get some feedback on the problem I'm trying to solve here. We'd like to be able to ship packages with verifiable security xattrs, but right now EVM makes this difficult due to its requirement that the inode number be encoded in the hmac. This patchset is intended to make it possible to protect a subset of metadata rather than all of it, and also to permit using EVM digital signatures in a similar way to how IMA digital signatures can be used now (ie, protecting the metadata using public/private crypto rather than having a local symmetric key and generating the HMACs locally). The expected workflow is:

1) During package build or mirroring process, appropriate security metadata is added (IMA hash, selinux label, etc)
2) An EVM digital signature is generated based purely on the security metadata present during the build or mirroring process
3) IMA is extended to allow it to force EVM validation during appraisal even if no symmetric EVM key has been added, which allows IMA appraisal to appraise not only the IMA hash but also the additional metadata
4) If EVM is never enabled, binaries are purely validated using the EVM digital signatures and are not transitioned to using HMACs
5) If EVM is desired, userland can set the set of metadata to be incorporated into the EVM HMAC before enabling EVM

Earlier this year there were discussions on defining a portable EVM signature, that could be included in software packages.

The reason for including as much metadata as possible in the HMAC is to limit cut & paste attacks. For this reason, the portable data is only used in transmission, not on disk.

A new EVM type is defined that does not convert the EVM signature to an HMAC.

Mikhail's patches:
https://sourceforge.net/p/linux-ima/mailman/linux-ima-user/thread/2017
0113072602.4ffaa30a@totoro/

Quoted 6 lines · Mimi Zohar

Earlier this year there were discussions on defining a portable EVM signature, that could be included in software packages.

The reason for including as much metadata as possible in the HMAC is to limit cut & paste attacks. For this reason, the portable data is only used in transmission, not on disk.

The concern is that two identical copies of a file may exist, but with different security contexts, and that not protecting the inode would allow an attacker to copy the security metadata from one file onto the other? This presumably only has meaning if they're on separate filesystems, since otherwise the attacker could just delete one file and hardlink the other to the former's location? I think that for our purposes this isn't a big deal.

Quoted 6 lines

A new EVM type is defined that does not convert the EVM signature to an HMAC.

Mikhail's patches:
https://sourceforge.net/p/linux-ima/mailman/linux-ima-user/thread/2017
0113072602.4ffaa30a@totoro/

That looks broadly like what we want, but I think there's some advantage in maintaining the flexibility of choosing which information is embedded. One additional option would be to allow userland to place a restriction on which options *must* be present, ie local policy could refuse to allow any signatures that didn't include a specific set of metadata.

One of the reasons we're interested in allowing the use of signatures rather than HMACs is to avoid the case where a machine being compromised would allow an attacker to obtain the symmetric key and drop new appropriately HMACed binaries on the system that would persist even if the kernel was updated to fix the vulnerability.

Without the inode included in the HMAC calculation, the same file could exist as a different file name on the same file system. No need for the two files to be on different file systems.

Quoted 5 lines

One of the reasons we're interested in allowing the use of signatures rather than HMACs is to avoid the case where a machine being compromised would allow an attacker to obtain the symmetric key and drop new appropriately HMACed binaries on the system that would persist even if the kernel was updated to fix the vulnerability.

Assuming you're using a trusted key (TPM based key) to encrypt/decrypt the EVM key (trusted key), then such an attack would require root privileges with the ability to read kernel memory. The EVM key is never exposed to userspace in the clear.

Quoted 3 lines · Mimi Zohar

Without the inode included in the HMAC calculation, the same file could exist as a different file name on the same file system. No need for the two files to be on different file systems.

But if I create a hardlink to an existing file then I get the same file with the same inode number and two different names on the same filesystem, and so security.evm would still match?

Quoted 10 lines

Quoted 5 lines

One of the reasons we're interested in allowing the use of signatures rather than HMACs is to avoid the case where a machine being compromised would allow an attacker to obtain the symmetric key and drop new appropriately HMACed binaries on the system that would persist even if the kernel was updated to fix the vulnerability.

Assuming you're using a trusted key (TPM based key) to encrypt/decrypt the EVM key (trusted key), then such an attack would require root privileges with the ability to read kernel memory. The EVM key is never exposed to userspace in the clear.

That's a case that we need to be worried about. Trusted boot means we can ensure that a system boots an updated kernel, but if the attacker has been able to drop a modified sshd with a valid hmac onto the system then we have fewer guarantees about the integrity. We could continue using signatures for security.ima to avoid that, but then we lose the performance benefits of the hmac and also don't have the same level of guarantees around the other security metadata.

Quoted 5 lines · Matthew Garrett

Quoted 3 lines · Mimi Zohar

Without the inode included in the HMAC calculation, the same file could exist as a different file name on the same file system. No need for the two files to be on different file systems.

Quoted 3 lines

But if I create a hardlink to an existing file then I get the same file with the same inode number and two different names on the same filesystem, and so security.evm would still match?

True, with a hard link that would be the case, but by the same file, I meant a copy of the original file, not a hard link to the file.

Quoted 5 lines

Quoted 4 lines

Assuming you're using a trusted key (TPM based key) to encrypt/decrypt the EVM key (trusted key), then such an attack would require root privileges with the ability to read kernel memory. The EVM key is never exposed to userspace in the clear.

Quoted 7 lines

That's a case that we need to be worried about. Trusted boot means we can ensure that a system boots an updated kernel, but if the attacker has been able to drop a modified sshd with a valid hmac onto the system then we have fewer guarantees about the integrity. We could continue using signatures for security.ima to avoid that, but then we lose the performance benefits of the hmac and also don't have the same level of guarantees around the other security metadata.

I think you mean "secure boot", not "trusted boot", in this case.

The original understanding was that IMA/EVM would enforce integrity and not enforce mandatory access control (MAC). The LSMs (eg. SELinux) would be responsible for MAC. Separation of duties.

With that understanding, if the LSM allows a file to be "dropped" onto
the file system of a running system, IMA/EVM will hash and hmac the
permitted file.

I don't understand where you're going with this train of thought. If you're trying to make a case for EVM to run with only security.evm signatures, then you wouldn't refer to the HMAC benefits. If you're trying to make a case for EVM signatures, with the inode they're not portable, without the inode, they are susceptible to a cut and paste attack.

Quoted 3 lines

The original understanding was that IMA/EVM would enforce integrity and not enforce mandatory access control (MAC). The LSMs (eg. SELinux) would be responsible for MAC. Separation of duties.

The kernel's security track record isn't sufficient to be able to assert that any kernel secrets can be kept secret, so we're left wanting integrity guarantees without relying on that.

Quoted 10 lines

With that understanding, if the LSM allows a file to be "dropped" onto
the file system of a running system, IMA/EVM will hash and hmac the
permitted file.

I don't understand where you're going with this train of thought. If you're trying to make a case for EVM to run with only security.evm signatures, then you wouldn't refer to the HMAC benefits. If you're trying to make a case for EVM signatures, with the inode they're not portable, without the inode, they are susceptible to a cut and paste attack.

I'm arguing that (for our case at least) the only way we can use IMA is to rely on using a digital signature - we can either have that digital signature be in security.ima, or we can have it in security.evm. Since we need that signature in any case, we derive no benefit from having security.evm be an hmac - our two reasonable choices are:

1) security.ima as a digital signature, security.evm as an hmac
2) security.ima as a hash, security.evm as a digital signature

I'm not really clear on what attacks are prevented by using the inode number. If I'm able to preserve all the other security metadata when copying a file, I can just create a hardlink to the original instead and have the same outcome.

Quoted 7 lines · Matthew Garrett

I'm arguing that (for our case at least) the only way we can use IMA is to rely on using a digital signature - we can either have that digital signature be in security.ima, or we can have it in security.evm. Since we need that signature in any case, we derive no benefit from having security.evm be an hmac - our two reasonable choices are:

Quoted 2 lines

1) security.ima as a digital signature, security.evm as an hmac
2) security.ima as a hash, security.evm as a digital signature

There's a major difference between security.ima containing a file hash vs a signature. A signature, assuming the file_check hook is in policy, prevents the file from being modified, making the file "immutable".

Quoted 4 lines

I'm not really clear on what attacks are prevented by using the inode number. If I'm able to preserve all the other security metadata when copying a file, I can just create a hardlink to the original instead and have the same outcome.

The issue is the ability of having different security metadata, not the same security metadata. (I need to refresh my memory as to hard links, and whether they can have different security metadata.)

Originally the UUID was not included in the HMAC calculation. Perhaps the patch description of commit 74de668 "evm: add file system uuid to EVM hmac" will help clarify the reasoning for including the inode and uuid in the hmac calculation.

Quoted 8 lines · Mimi Zohar

Quoted 7 lines · Matthew Garrett

I'm arguing that (for our case at least) the only way we can use IMA is to rely on using a digital signature - we can either have that digital signature be in security.ima, or we can have it in security.evm. Since we need that signature in any case, we derive no benefit from having security.evm be an hmac - our two reasonable choices are:

Quoted 7 lines

Quoted 2 lines

1) security.ima as a digital signature, security.evm as an hmac
2) security.ima as a hash, security.evm as a digital signature

There's a major difference between security.ima containing a file hash vs a signature. A signature, assuming the file_check hook is in policy, prevents the file from being modified, making the file "immutable".

But the same is effectively true if security.evm is a digital signature and there's no symmetric key? For what we want to do (ensure that executables that are allowed to run with elevated privileges haven't been tampered with), that's completely ok.

Quoted 5 lines

Quoted 4 lines

I'm not really clear on what attacks are prevented by using the inode number. If I'm able to preserve all the other security metadata when copying a file, I can just create a hardlink to the original instead and have the same outcome.

Quoted 3 lines

The issue is the ability of having different security metadata, not the same security metadata. (I need to refresh my memory as to hard links, and whether they can have different security metadata.)

If the security metadata is different then copying another security.evm will fail, surely?

Quoted 2 lines · Matthew Garrett

If the security metadata is different then copying another security.evm will fail, surely?

A copy of the file could exist with a valid hmac on the system with different security xattrs. Without the inode/uuid, the xattrs could be cut & pasted.

Quoted 7 lines · Mimi Zohar

Quoted 2 lines · Matthew Garrett

If the security metadata is different then copying another security.evm will fail, surely?

A copy of the file could exist with a valid hmac on the system with different security xattrs. Without the inode/uuid, the xattrs could be cut & pasted.

So we have /usr/bin/a and /usr/bin/b, which are identical but have different security contexts. Outside some unusual cases, if I have the ability to modify /usr/bin/b's security.evm, I can delete /usr/bin/b. I can then also just do:

ln -f /usr/bin/a /usr/bin/b

and /usr/bin/b now has the same security context as /usr/bin/a, including security.evm.

Quoted 2 lines · Matthew Garrett

If /home is on the same filesystem as / (which is a pretty common case) then ln -f /usr/bin/a /home/bin/b will work just as well.

Yes, assuming you have permissions on the running system.

Quoted 8 lines

Quoted 4 lines

I'm not really clear on what attacks are prevented by using the inode number. If I'm able to preserve all the other security metadata when copying a file, I can just create a hardlink to the original instead and have the same outcome.

The issue is the ability of having different security metadata, not the same security metadata. (I need to refresh my memory as to hard links, and whether they can have different security metadata.)

If the security metadata is different then copying another security.evm will fail, surely?

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

I'm not really clear on what attacks are prevented by using the inode number. If I'm able to preserve all the other security metadata when copying a file, I can just create a hardlink to the original instead and have the same outcome.

The issue is the ability of having different security metadata, not the same security metadata. (I need to refresh my memory as to hard links, and whether they can have different security metadata.)

Quoted 2 lines

If the security metadata is different then copying another security.evm will fail, surely?

The assumption here is that security.ima exists and is included in the HMAC calculation. For files which are not included in the IMA policy, the only thing binding the file data and metadata is the i_ino and uuid.

Quoted 9 lines · Mimi Zohar

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

I'm not really clear on what attacks are prevented by using the inode number. If I'm able to preserve all the other security metadata when copying a file, I can just create a hardlink to the original instead and have the same outcome.

The issue is the ability of having different security metadata, not the same security metadata. (I need to refresh my memory as to hard links, and whether they can have different security metadata.)

Quoted 7 lines

Quoted 2 lines

If the security metadata is different then copying another security.evm will fail, surely?

The assumption here is that security.ima exists and is included in the HMAC calculation. For files which are not included in the IMA policy, the only thing binding the file data and metadata is the i_ino and uuid.

Ok, that makes sense. But for cases where we do have security.ima, the inode doesn't seem to provide additional security but does make deployment more difficult. Does supporting this use case seem reasonable?

Quoted 4 lines · Matthew Garrett

Ok, that makes sense. But for cases where we do have security.ima, the inode doesn't seem to provide additional security but does make deployment more difficult. Does supporting this use case seem reasonable?

Yes!

Quoted 6 lines · Mimi Zohar

Quoted 4 lines · Matthew Garrett

Ok, that makes sense. But for cases where we do have security.ima, the inode doesn't seem to provide additional security but does make deployment more difficult. Does supporting this use case seem reasonable?

Quoted 1 line

Yes!

Excellent. This means defining a new signature type - the two options seem to be Mikhail's portable format, or the approach I took of having the signature define which metadata is included. Do you have a preference?

? Mon, 09 Oct 2017 17:10:49 -0400
Mimi Zohar <[email protected]> ?????:

Quoted 30 lines · Mikhail Kurinnoi

Quoted 29 lines

? Mon, 09 Oct 2017 14:40:41 -0400
Mimi Zohar <[email protected]> ?????:

Quoted 11 lines · Matthew Garrett

Quoted 10 lines

Quoted 7 lines · Mimi Zohar

Quoted 4 lines · Matthew Garrett

Ok, that makes sense. But for cases where we do have security.ima, the inode doesn't seem to provide additional security but does make deployment more difficult. Does supporting this use case seem reasonable?

Yes!

Quoted 8 lines

Quoted 4 lines

Excellent. This means defining a new signature type - the two options seem to be Mikhail's portable format, or the approach I took of having the signature define which metadata is included. Do you have a preference?

We now understand that as long as the EVM signature includes security.ima, it is safe not to include the i_ino/uuid. This new format can be written to disk.

But, isn't this mean we could have this scenario of offline manipulations:
1) store old file with xattrs;
2) wait;
3) replace new file with fixed exploits on old one.

Quoted 7 lines

Quoted 3 lines

Since we don't have directory tree protection yet and we don't use i_ino, someone could reuse old files more easy during offline manipulations. Right?

As long as the new EVM signature format requires the existence of a security.ima xattr, I don't see how. The new EVM signature format would not be replaced with an HMAC.

I understood the idea.

Looks like portable EVM format support proposed by Matthew, could be easy realized. Probably, will be good idea add only this one, test it, and later add immutable EVM format and portable EVM format that converted into HMAC (that I proposed in patch set)?

If no one ask for portable EVM format that converted into HMAC, do we really need push all in one bunch?

[Cc'ing Dmitry Kasatkin]

Quoted 46 lines · Mikhail Kurinnoi

? Mon, 09 Oct 2017 17:10:49 -0400
Mimi Zohar <[email protected]> ?????:

Quoted 32 lines · Mikhail Kurinnoi

Quoted 31 lines

? Mon, 09 Oct 2017 14:40:41 -0400
Mimi Zohar <[email protected]> ?????:

Quoted 13 lines · Matthew Garrett

Quoted 12 lines

Quoted 9 lines · Mimi Zohar

Quoted 5 lines · Matthew Garrett

Ok, that makes sense. But for cases where we do have security.ima, the inode doesn't seem to provide additional security but does make deployment more difficult. Does supporting this use case seem reasonable?

Yes!

Quoted 8 lines

Quoted 4 lines

Excellent. This means defining a new signature type - the two options seem to be Mikhail's portable format, or the approach I took of having the signature define which metadata is included. Do you have a preference?

We now understand that as long as the EVM signature includes security.ima, it is safe not to include the i_ino/uuid. This new format can be written to disk.

But, isn't this mean we could have this scenario of offline manipulations:
1) store old file with xattrs;
2) wait;
3) replace new file with fixed exploits on old one.

Quoted 7 lines

Quoted 3 lines

Since we don't have directory tree protection yet and we don't use i_ino, someone could reuse old files more easy during offline manipulations. Right?

As long as the new EVM signature format requires the existence of a security.ima xattr, I don't see how. The new EVM signature format would not be replaced with an HMAC.

I understood the idea.

Quoted 7 lines

Looks like portable EVM format support proposed by Matthew, could be easy realized. Probably, will be good idea add only this one, test it, and later add immutable EVM format and portable EVM format that converted into HMAC (that I proposed in patch set)?

If no one ask for portable EVM format that converted into HMAC, do we really need push all in one bunch?

It looks like Dmitry already defined a new "immutable" EVM signature format in ima-evm-utils and posted the corresponding patch to linux- ima-devel a long time ago.

The new "immutable" EVM signature doesn't include the i_ino or generation.

For now, we don't have ready for upstream "immutable" EVM signature format support patch. Both, Dmitry's and my, patches need more work in order to prevent file's data changes (in case of IMA hash) and metadata changes for files signed by "immutable" EVM xattr (same idea as we already have for IMA digsig, that prevent file's data change).

Quoted 5 lines · Mikhail Kurinnoi

For now, we don't have ready for upstream "immutable" EVM signature format support patch. Both, Dmitry's and my, patches need more work in order to prevent file's data changes (in case of IMA hash) and metadata changes for files signed by "immutable" EVM xattr (same idea as we already have for IMA digsig, that prevent file's data change).

After looking at your patches again, I think we should combine the "immutable" and "portable" concepts so that the new "portable" signature type is written out and considered "immutable".

Dmitry's patch does prevent the file from changing, but that code is in IMA, but should be in EVM. I agree we can defer preventing the file from changing.

Mimi

Hi all,

[switched to plain text]

I will check Mikhail's patches.
Give me a moment.

Thanks,
Dmitry

Quoted 11 lines · Mimi Zohar

Quoted 5 lines · Mikhail Kurinnoi

For now, we don't have ready for upstream "immutable" EVM signature format support patch. Both, Dmitry's and my, patches need more work in order to prevent file's data changes (in case of IMA hash) and metadata changes for files signed by "immutable" EVM xattr (same idea as we already have for IMA digsig, that prevent file's data change).

After looking at your patches again, I think we should combine the "immutable" and "portable" concepts so that the new "portable" signature type is written out and considered "immutable".

Quoted 6 lines

Dmitry's patch does prevent the file from changing, but that code is in IMA, but should be in EVM. I agree we can defer preventing the file from changing.

Mimi

--
Thanks,
Dmitry

Can you please point me to the patchset email?

Quoted 35 lines · Dmitry Kasatkin

Hi all,

[switched to plain text]

I will check Mikhail's patches.
Give me a moment.

Thanks,
Dmitry

Quoted 11 lines · Mimi Zohar

Quoted 5 lines · Mikhail Kurinnoi

For now, we don't have ready for upstream "immutable" EVM signature format support patch. Both, Dmitry's and my, patches need more work in order to prevent file's data changes (in case of IMA hash) and metadata changes for files signed by "immutable" EVM xattr (same idea as we already have for IMA digsig, that prevent file's data change).

After looking at your patches again, I think we should combine the "immutable" and "portable" concepts so that the new "portable" signature type is written out and considered "immutable".

Quoted 6 lines

Dmitry's patch does prevent the file from changing, but that code is in IMA, but should be in EVM. I agree we can defer preventing the file from changing.

Mimi

--
Thanks,
Dmitry

Quoted 1 line · Dmitry Kasatkin

Can you please point me to the patchset email?

This was the start of the lengthy discussion -
https://www.spinics.net/lists/linux-integrity/msg00035.html

Quoted 41 lines

Quoted 35 lines · Dmitry Kasatkin

Hi all,

[switched to plain text]

I will check Mikhail's patches.
Give me a moment.

Thanks,
Dmitry

Quoted 11 lines · Mimi Zohar

Quoted 5 lines · Mikhail Kurinnoi

For now, we don't have ready for upstream "immutable" EVM signature format support patch. Both, Dmitry's and my, patches need more work in order to prevent file's data changes (in case of IMA hash) and metadata changes for files signed by "immutable" EVM xattr (same idea as we already have for IMA digsig, that prevent file's data change).

After looking at your patches again, I think we should combine the "immutable" and "portable" concepts so that the new "portable" signature type is written out and considered "immutable".

Quoted 6 lines

Dmitry's patch does prevent the file from changing, but that code is in IMA, but should be in EVM. I agree we can defer preventing the file from changing.

Mimi

--
Thanks,
Dmitry

May be Mikhail could share GIT url to look somewhere. To see latest bits.

Dmitry

May be Mikhail could share GIT url to look somewhere. To see latest bits.

Hi Dmitry,

Quoted 2 lines · Dmitry Kasatkin

May be Mikhail could share GIT url to look somewhere. To see latest bits.

Please bottom post in the future.

Summary:
Mikhail's patches were posted earlier this year. His patches defined a portable EVM signature, which was never written out to disk, but after being verified, was written out as an HMAC. This was based on my understanding that the i_ino/uuid is required to prevent a cut & paste attack.

In the recent discussions, Matthew wanted to know why the i_ino/uuid is required. After going around and around discussing it, it turns out including security.ima is equivalent to including the i_ino/uuid.
The i_ino/uuid is only necessary to prevent a cut and paste attack,
when security.ima is not included in the security.evm hmac/signature.

We're at the point of making the portable EVM signature immutable. By immutable, we mean that it isn't re-written as an HMAC. It is based on your ima-evm-utils support.

Mikhail, Matthew, did I leave anything out?

Mimi

Quoted 6 lines · Mimi Zohar

Hi Dmitry,

Quoted 2 lines · Dmitry Kasatkin

May be Mikhail could share GIT url to look somewhere. To see latest bits.

Quoted 8 lines

Please bottom post in the future.

Summary:
Mikhail's patches were posted earlier this year. His patches defined a portable EVM signature, which was never written out to disk, but after being verified, was written out as an HMAC. This was based on my understanding that the i_ino/uuid is required to prevent a cut & paste attack.

I checked Mikhail patches. In his patches, immutable is normal evm signature but not replaceable with hmac.

2) portable EVM digsig version, aimed to protect archived file's meta data from manipulations.

What is the case of manipulation? hmac protects that..

Quoted 6 lines

In the recent discussions, Matthew wanted to know why the i_ino/uuid is required. After going around and around discussing it, it turns out including security.ima is equivalent to including the i_ino/uuid.
The i_ino/uuid is only necessary to prevent a cut and paste attack,
when security.ima is not included in the security.evm hmac/signature.

If I recall, we had such discussion in the chat about i_no/uuid.

if I recall right, not including them was a compromise for "portability"? Archive could be unpacked with xattrs and signatures are still valid. tar --xattrs
cp --preserve=xattr

But how security.ima will protect against cut and paste attack? Attacker can take any other file together with metadata and it will be valid one.

Quoted 8 lines

We're at the point of making the portable EVM signature immutable. By immutable, we mean that it isn't re-written as an HMAC. It is based on your ima-evm-utils support.

Mikhail, Matthew, did I leave anything out?

Mimi

But how security.ima will protect against cut and paste attack? Attacker can take any other file together with metadata and it will be valid one.

Quoted 3 lines · Dmitry Kasatkin

But how security.ima will protect against cut and paste attack? Attacker can take any other file together with metadata and it will be valid one.

Unless the hashing algorithm is broken, the two files will need to be identical in order for security.ima to match. And if the two files are identical then an attacker can simply delete one and create a hardlink to the other, which will have the same inode.

Hi Dmitry,

Quoted 2 lines · Dmitry Kasatkin

May be Mikhail could share GIT url to look somewhere. To see latest bits.

Please bottom post in the future.

Summary:
Mikhail's patches were posted earlier this year. His patches defined a portable EVM signature, which was never written out to disk, but after being verified, was written out as an HMAC. This was based on my understanding that the i_ino/uuid is required to prevent a cut & paste attack.

In the recent discussions, Matthew wanted to know why the i_ino/uuid is required. After going around and around discussing it, it turns out including security.ima is equivalent to including the i_ino/uuid.
The i_ino/uuid is only necessary to prevent a cut and paste attack,
when security.ima is not included in the security.evm hmac/signature.

We're at the point of making the portable EVM signature immutable. By immutable, we mean that it isn't re-written as an HMAC. It is based on your ima-evm-utils support.

Mikhail, Matthew, did I leave anything out?

Mimi

Quoted 4 lines · Mimi Zohar

We're at the point of making the portable EVM signature immutable. By immutable, we mean that it isn't re-written as an HMAC. It is based on your ima-evm-utils support.

Do you mean to have unconditionally immutable?

Quoted 8 lines · Matthew Garrett

Quoted 3 lines · Mimi Zohar

Without the inode included in the HMAC calculation, the same file could exist as a different file name on the same file system. No need for the two files to be on different file systems.

But if I create a hardlink to an existing file then I get the same file with the same inode number and two different names on the same filesystem, and so security.evm would still match?

True, with a hard link that would be the case, but by the same file, I meant a copy of the original file, not a hard link to the file.

Quoted 11 lines

Quoted 10 lines

Quoted 5 lines

One of the reasons we're interested in allowing the use of signatures rather than HMACs is to avoid the case where a machine being compromised would allow an attacker to obtain the symmetric key and drop new appropriately HMACed binaries on the system that would persist even if the kernel was updated to fix the vulnerability.

Assuming you're using a trusted key (TPM based key) to encrypt/decrypt the EVM key (trusted key), then such an attack would require root privileges with the ability to read kernel memory. The EVM key is never exposed to userspace in the clear.

Quoted 7 lines

That's a case that we need to be worried about. Trusted boot means we can ensure that a system boots an updated kernel, but if the attacker has been able to drop a modified sshd with a valid hmac onto the system then we have fewer guarantees about the integrity. We could continue using signatures for security.ima to avoid that, but then we lose the performance benefits of the hmac and also don't have the same level of guarantees around the other security metadata.

I think you mean "secure boot", not "trusted boot", in this case.

The original understanding was that IMA/EVM would enforce integrity and not enforce mandatory access control (MAC). The LSMs (eg. SELinux) would be responsible for MAC. Separation of duties.

With that understanding, if the LSM allows a file to be "dropped" onto
the file system of a running system, IMA/EVM will hash and hmac the
permitted file.

I don't understand where you're going with this train of thought. If you're trying to make a case for EVM to run with only security.evm signatures, then you wouldn't refer to the HMAC benefits. If you're trying to make a case for EVM signatures, with the inode they're not portable, without the inode, they are susceptible to a cut and paste attack.

Mickhail's proposed patches resolves this by having a portable EVM signature that is never written to disk, but converted to an HMAC.

Mimi

Quoted 8 lines · Matthew Garrett

Quoted 6 lines · Mimi Zohar

Earlier this year there were discussions on defining a portable EVM signature, that could be included in software packages.

The reason for including as much metadata as possible in the HMAC is to limit cut & paste attacks. For this reason, the portable data is only used in transmission, not on disk.

Quoted 7 lines

The concern is that two identical copies of a file may exist, but with different security contexts, and that not protecting the inode would allow an attacker to copy the security metadata from one file onto the other? This presumably only has meaning if they're on separate filesystems, since otherwise the attacker could just delete one file and hardlink the other to the former's location? I think that for our purposes this isn't a big deal.

Without the inode included in the HMAC calculation, the same file could exist as a different file name on the same file system. No need for the two files to be on different file systems.

Quoted 7 lines

Quoted 6 lines

A new EVM type is defined that does not convert the EVM signature to an HMAC.

Mikhail's patches:
https://sourceforge.net/p/linux-ima/mailman/linux-ima-user/thread/2017
0113072602.4ffaa30a@totoro/

Quoted 6 lines

That looks broadly like what we want, but I think there's some advantage in maintaining the flexibility of choosing which information is embedded. One additional option would be to allow userland to place a restriction on which options *must* be present, ie local policy could refuse to allow any signatures that didn't include a specific set of metadata.

This introduces a new level of complexity, which I'm not sure is warranted.

Quoted 5 lines

One of the reasons we're interested in allowing the use of signatures rather than HMACs is to avoid the case where a machine being compromised would allow an attacker to obtain the symmetric key and drop new appropriately HMACed binaries on the system that would persist even if the kernel was updated to fix the vulnerability.

Assuming you're using a trusted key (TPM based key) to encrypt/decrypt the EVM key (trusted key), then such an attack would require root privileges with the ability to read kernel memory. The EVM key is never exposed to userspace in the clear.