<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/security/integrity/evm, branch linus/master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/security/integrity/evm?h=linus%2Fmaster</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/security/integrity/evm?h=linus%2Fmaster'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-05-16T12:14:38Z</updated>
<entry>
<title>evm: Clean up some variables</title>
<updated>2022-05-16T12:14:38Z</updated>
<author>
<name>Stefan Berger</name>
<email>stefanb@linux.ibm.com</email>
</author>
<published>2022-05-13T17:41:05Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=4c41186ff394680cbde32a6a29e539f1e6036a47'/>
<id>urn:sha1:4c41186ff394680cbde32a6a29e539f1e6036a47</id>
<content type='text'>
Make hmac_tfm static since it's not used anywhere else besides the file
it is in.

Remove declaration of hash_tfm since it doesn't exist.

Signed-off-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>evm: Return INTEGRITY_PASS for enum integrity_status value '0'</title>
<updated>2022-05-16T12:14:38Z</updated>
<author>
<name>Stefan Berger</name>
<email>stefanb@linux.ibm.com</email>
</author>
<published>2022-05-12T11:43:07Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=e11afdbb22a39807e1f0cb707974ddd2c03e90a4'/>
<id>urn:sha1:e11afdbb22a39807e1f0cb707974ddd2c03e90a4</id>
<content type='text'>
Return INTEGRITY_PASS for the enum integrity_status rather than 0.

Signed-off-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>EVM: fix the evm= __setup handler return value</title>
<updated>2022-02-22T23:11:33Z</updated>
<author>
<name>Randy Dunlap</name>
<email>rdunlap@infradead.org</email>
</author>
<published>2022-02-22T21:45:18Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=f2544f5e6c691679d56bb38637d2f347075b36fa'/>
<id>urn:sha1:f2544f5e6c691679d56bb38637d2f347075b36fa</id>
<content type='text'>
__setup() handlers should return 1 if the parameter is handled.
Returning 0 causes the entire string to be added to init's
environment strings (limited to 32 strings), unnecessarily polluting it.

Using the documented string "evm=fix" causes an Unknown parameter message:
  Unknown kernel command line parameters
  "BOOT_IMAGE=/boot/bzImage-517rc5 evm=fix", will be passed to user space.

and that string is added to init's environment string space:
  Run /sbin/init as init process
    with arguments:
     /sbin/init
    with environment:
     HOME=/
     TERM=linux
     BOOT_IMAGE=/boot/bzImage-517rc5
     evm=fix

With this change, using "evm=fix" acts as expected and an invalid
option ("evm=evm") causes a warning to be printed:
  evm: invalid "evm" mode
but init's environment is not polluted with this string, as expected.

Fixes: 7102ebcd65c1 ("evm: permit only valid security.evm xattrs to be updated")
Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Reported-by: Igor Zhbanov &lt;i.zhbanov@omprussia.ru&gt;
Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>evm: mark evm_fixmode as __ro_after_init</title>
<updated>2021-10-28T22:52:49Z</updated>
<author>
<name>Austin Kim</name>
<email>austin.kim@lge.com</email>
</author>
<published>2021-10-28T11:26:42Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=32ba540f3c2a7ef61ed5a577ce25069a3d714fc9'/>
<id>urn:sha1:32ba540f3c2a7ef61ed5a577ce25069a3d714fc9</id>
<content type='text'>
The evm_fixmode is only configurable by command-line option and it is never
modified outside initcalls, so declaring it with __ro_after_init is better.

Signed-off-by: Austin Kim &lt;austin.kim@lge.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>evm: Check xattr size discrepancy between kernel and user</title>
<updated>2021-06-21T12:34:21Z</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2021-06-21T12:29:12Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=907a399de7b0566236c480d0c01ff52220532fb1'/>
<id>urn:sha1:907a399de7b0566236c480d0c01ff52220532fb1</id>
<content type='text'>
The kernel and the user obtain an xattr value in two different ways:

kernel (EVM): uses vfs_getxattr_alloc() which obtains the xattr value from
              the filesystem handler (raw value);

user (ima-evm-utils): uses vfs_getxattr() which obtains the xattr value
                      from the LSMs (normalized value).

Normally, this does not have an impact unless security.selinux is set with
setfattr, with a value not terminated by '\0' (this is not the recommended
way, security.selinux should be set with the appropriate tools such as
chcon and restorecon).

In this case, the kernel and the user see two different xattr values: the
former sees the xattr value without '\0' (raw value), the latter sees the
value with '\0' (value normalized by SELinux).

This could result in two different verification outcomes from EVM and
ima-evm-utils, if a signature was calculated with a security.selinux value
terminated by '\0' and the value set in the filesystem is not terminated by
'\0'. The former would report verification failure due to the missing '\0',
while the latter would report verification success (because it gets the
normalized value with '\0').

This patch mitigates this issue by comparing in evm_calc_hmac_or_hash() the
size of the xattr returned by the two xattr functions and by warning the
user if there is a discrepancy.

Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Suggested-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>evm: output EVM digest calculation info</title>
<updated>2021-06-20T15:10:25Z</updated>
<author>
<name>Mimi Zohar</name>
<email>zohar@linux.ibm.com</email>
</author>
<published>2021-05-13T22:36:04Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=87ac3d002d567fac3527d6612865e81cfd783727'/>
<id>urn:sha1:87ac3d002d567fac3527d6612865e81cfd783727</id>
<content type='text'>
Output the data used in calculating the EVM digest and the resulting
digest as ascii hexadecimal strings.

Suggested-by: Lakshmi Ramasubramanian &lt;nramas@linux.microsoft.com&gt; (CONFIG_DYNAMIC_DEBUG)
Reviewed-by: Lakshmi Ramasubramanian &lt;nramas@linux.microsoft.com&gt;
Reported-by: kernel test robot &lt;lkp@intel.com&gt; (Use %zu for size_t)
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>ima/evm: Fix type mismatch</title>
<updated>2021-06-08T20:29:10Z</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2021-06-08T12:31:22Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=6b26285f44c9306747c609cb304f787f1933594c'/>
<id>urn:sha1:6b26285f44c9306747c609cb304f787f1933594c</id>
<content type='text'>
The endianness of a variable written to the measurement list cannot be
determined at compile time, as it depends on the value of the
ima_canonical_fmt global variable (set through a kernel option with the
same name if the machine is big endian).

If ima_canonical_fmt is false, the endianness of a variable is the same as
the machine; if ima_canonical_fmt is true, the endianness is little endian.
The warning arises due to this type of instruction:

var = cpu_to_leXX(var)

which tries to assign a value in little endian to a variable with native
endianness (little or big endian).

Given that the variables set with this instruction are not used in any
operation but just written to a buffer, it is safe to force the type of the
value being set to be the same of the type of the variable with:

var = (__force &lt;var type&gt;)cpu_to_leXX(var)

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>evm: Don't return an error in evm_write_xattrs() if audit is not enabled</title>
<updated>2021-06-03T14:03:40Z</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2021-05-28T07:38:12Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=d721c15fd519c08819fbc6de39b713e2ed1d9894'/>
<id>urn:sha1:d721c15fd519c08819fbc6de39b713e2ed1d9894</id>
<content type='text'>
This patch avoids that evm_write_xattrs() returns an error when audit is
not enabled. The ab variable can be NULL and still be passed to the other
audit_log_() functions, as those functions do not include any instruction.

Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>ima: Define new template fields xattrnames, xattrlengths and xattrvalues</title>
<updated>2021-06-02T22:56:13Z</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2021-06-01T08:23:38Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=8314b6732ae4e600bb933e108f96ce0176acb09c'/>
<id>urn:sha1:8314b6732ae4e600bb933e108f96ce0176acb09c</id>
<content type='text'>
This patch defines the new template fields xattrnames, xattrlengths and
xattrvalues, which contain respectively a list of xattr names (strings,
separated by |), lengths (u32, hex) and values (hex). If an xattr is not
present, the name and length are not displayed in the measurement list.

Reported-by: kernel test robot &lt;lkp@intel.com&gt; (Missing prototype def)
Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>evm: Verify portable signatures against all protected xattrs</title>
<updated>2021-06-01T19:17:31Z</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2021-05-28T07:38:09Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=8c7a703ec9787a1b45b024e9acd253328422dcbd'/>
<id>urn:sha1:8c7a703ec9787a1b45b024e9acd253328422dcbd</id>
<content type='text'>
Currently, the evm_config_default_xattrnames array contains xattr names
only related to LSMs which are enabled in the kernel configuration.
However, EVM portable signatures do not depend on local information and a
vendor might include in the signature calculation xattrs that are not
enabled in the target platform.

Just including all xattrs names in evm_config_default_xattrnames is not a
safe approach, because a target system might have already calculated
signatures or HMACs based only on the enabled xattrs. After applying this
patch, EVM would verify those signatures and HMACs with all xattrs instead.
The non-enabled ones, which could possibly exist, would cause a
verification error.

Thus, this patch adds a new field named enabled to the xattr_list
structure, which is set to true if the LSM associated to a given xattr name
is enabled in the kernel configuration. The non-enabled xattrs are taken
into account only in evm_calc_hmac_or_hash(), if the passed security.evm
type is EVM_XATTR_PORTABLE_DIGSIG.

The new function evm_protected_xattr_if_enabled() has been defined so that
IMA can include all protected xattrs and not only the enabled ones in the
measurement list, if the new template fields xattrnames, xattrlengths or
xattrvalues have been included in the template format.

Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
</feed>
