<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/security/integrity/ima/ima_main.c, branch linux-5.8.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.8.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.8.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2020-10-29T09:07:38Z</updated>
<entry>
<title>ima: Fix NULL pointer dereference in ima_file_hash</title>
<updated>2020-10-29T09:07:38Z</updated>
<author>
<name>KP Singh</name>
</author>
<published>2020-09-16T18:02:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4a4778394419ad462e36d85ca67560d2a60eccae'/>
<id>urn:sha1:4a4778394419ad462e36d85ca67560d2a60eccae</id>
<content type='text'>
[ Upstream commit aa662fc04f5b290b3979332588bf8d812b189962 ]

ima_file_hash can be called when there is no iint-&gt;ima_hash available
even though the inode exists in the integrity cache. It is fairly
common for a file to not have a hash. (e.g. an mknodat, prior to the
file being closed).

Another example where this can happen (suggested by Jann Horn):

Process A does:

	while(1) {
		unlink("/tmp/imafoo");
		fd = open("/tmp/imafoo", O_RDWR|O_CREAT|O_TRUNC, 0700);
		if (fd == -1) {
			perror("open");
			continue;
		}
		write(fd, "A", 1);
		close(fd);
	}

and Process B does:

	while (1) {
		int fd = open("/tmp/imafoo", O_RDONLY);
		if (fd == -1)
			continue;
    		char *mapping = mmap(NULL, 0x1000, PROT_READ|PROT_EXEC,
			 	     MAP_PRIVATE, fd, 0);
		if (mapping != MAP_FAILED)
			munmap(mapping, 0x1000);
		close(fd);
  	}

Due to the race to get the iint-&gt;mutex between ima_file_hash and
process_measurement iint-&gt;ima_hash could still be NULL.

Fixes: 6beea7afcc72 ("ima: add the ability to query the cached hash of a given file")
Signed-off-by: KP Singh &lt;kpsingh@google.com&gt;
Reviewed-by: Florent Revest &lt;revest@chromium.org&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ima: fix mprotect checking</title>
<updated>2020-06-12T15:30:18Z</updated>
<author>
<name>Mimi Zohar</name>
</author>
<published>2020-06-10T13:18:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4235b1a4efe19dd0309250170bbf0aa95e559626'/>
<id>urn:sha1:4235b1a4efe19dd0309250170bbf0aa95e559626</id>
<content type='text'>
Make sure IMA is enabled before checking mprotect change.  Addresses
report of a 3.7% regression of boot-time.dhcp.

Fixes: 8eb613c0b8f1 ("ima: verify mprotect change is consistent with mmap policy")
Reported-by: kernel test robot &lt;rong.a.chen@intel.com&gt;
Reviewed-by: Lakshmi Ramasubramanian &lt;nramas@linux.microsoft.com&gt;
Tested-by: Xing Zhengjun &lt;zhengjun.xing@linux.intel.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>ima: verify mprotect change is consistent with mmap policy</title>
<updated>2020-05-22T18:41:04Z</updated>
<author>
<name>Mimi Zohar</name>
</author>
<published>2020-05-03T05:00:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8eb613c0b8f19627ba1846dcf78bb2c85edbe8dd'/>
<id>urn:sha1:8eb613c0b8f19627ba1846dcf78bb2c85edbe8dd</id>
<content type='text'>
Files can be mmap'ed read/write and later changed to execute to circumvent
IMA's mmap appraise policy rules.  Due to locking issues (mmap semaphore
would be taken prior to i_mutex), files can not be measured or appraised at
this point.  Eliminate this integrity gap, by denying the mprotect
PROT_EXECUTE change, if an mmap appraise policy rule exists.

On mprotect change success, return 0.  On failure, return -EACESS.

Reviewed-by: Lakshmi Ramasubramanian &lt;nramas@linux.microsoft.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>ima: Evaluate error in init_ima()</title>
<updated>2020-04-20T02:03:39Z</updated>
<author>
<name>Roberto Sassu</name>
</author>
<published>2020-03-25T10:47:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e144d6b265415ddbdc54b3f17f4f95133effa5a8'/>
<id>urn:sha1:e144d6b265415ddbdc54b3f17f4f95133effa5a8</id>
<content type='text'>
Evaluate error in init_ima() before register_blocking_lsm_notifier() and
return if not zero.

Cc: stable@vger.kernel.org # 5.3.x
Fixes: b16942455193 ("ima: use the lsm policy update notifier")
Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Reviewed-by: James Morris &lt;jamorris@linux.microsoft.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>integrity: Remove duplicate pr_fmt definitions</title>
<updated>2020-02-28T19:32:58Z</updated>
<author>
<name>Tushar Sugandhi</name>
</author>
<published>2020-02-19T00:06:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=555d6d71d57c4a2e4ff750f6a41d2b7d7c861863'/>
<id>urn:sha1:555d6d71d57c4a2e4ff750f6a41d2b7d7c861863</id>
<content type='text'>
The #define for formatting log messages, pr_fmt, is duplicated in the
files under security/integrity.

This change moves the definition to security/integrity/integrity.h and
removes the duplicate definitions in the other files under
security/integrity.

With this change, the messages in the following files will be prefixed
with 'integrity'.

     security/integrity/platform_certs/platform_keyring.c
     security/integrity/platform_certs/load_powerpc.c
     security/integrity/platform_certs/load_uefi.c
     security/integrity/iint.c

     e.g. "integrity: Error adding keys to platform keyring %s\n"

And the messages in the following file will be prefixed with 'ima'.

     security/integrity/ima/ima_mok.c

     e.g. "ima: Allocating IMA blacklist keyring.\n"

For the rest of the files under security/integrity, there will be no
change in the message format.

Suggested-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Suggested-by: Joe Perches &lt;joe@perches.com&gt;
Signed-off-by: Tushar Sugandhi &lt;tusharsu@linux.microsoft.com&gt;
Reviewed-by: Lakshmi Ramasubramanian &lt;nramas@linux.microsoft.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>IMA: Add log statements for failure conditions</title>
<updated>2020-02-28T19:32:58Z</updated>
<author>
<name>Tushar Sugandhi</name>
</author>
<published>2020-02-19T00:06:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=72ec611c64766795c495d88a4ad5d1180eb61bd8'/>
<id>urn:sha1:72ec611c64766795c495d88a4ad5d1180eb61bd8</id>
<content type='text'>
process_buffer_measurement() does not have log messages for failure
conditions.

This change adds a log statement in the above function.

Suggested-by: Joe Perches &lt;joe@perches.com&gt;
Signed-off-by: Tushar Sugandhi &lt;tusharsu@linux.microsoft.com&gt;
Reviewed-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Reviewed-by: Lakshmi Ramasubramanian &lt;nramas@linux.microsoft.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>ima: add the ability to query the cached hash of a given file</title>
<updated>2020-01-22T20:22:51Z</updated>
<author>
<name>Florent Revest</name>
</author>
<published>2020-01-13T09:42:44Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6beea7afcc72b86986080ea1d228a42f2000f2a9'/>
<id>urn:sha1:6beea7afcc72b86986080ea1d228a42f2000f2a9</id>
<content type='text'>
This allows other parts of the kernel (perhaps a stacked LSM allowing
system monitoring, eg. the proposed KRSI LSM [1]) to retrieve the hash
of a given file from IMA if it's present in the iint cache.

It's true that the existence of the hash means that it's also in the
audit logs or in /sys/kernel/security/ima/ascii_runtime_measurements,
but it can be difficult to pull that information out for every
subsequent exec. This is especially true if a given host has been up
for a long time and the file was first measured a long time ago.

It should be kept in mind that this function gives access to cached
entries which can be removed, for instance on security_inode_free().

This is based on Peter Moody's patch:
 https://sourceforge.net/p/linux-ima/mailman/message/33036180/

[1] https://lkml.org/lkml/2019/9/10/393

Signed-off-by: Florent Revest &lt;revest@google.com&gt;
Reviewed-by: KP Singh &lt;kpsingh@chromium.org&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>IMA: Add support to limit measuring keys</title>
<updated>2019-12-12T13:53:50Z</updated>
<author>
<name>Lakshmi Ramasubramanian</name>
</author>
<published>2019-12-11T16:47:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e9085e0ad38a333012629d815c203155d61ebe7e'/>
<id>urn:sha1:e9085e0ad38a333012629d815c203155d61ebe7e</id>
<content type='text'>
Limit measuring keys to those keys being loaded onto a given set of
keyrings only and when the user id (uid) matches if uid is specified
in the policy.

This patch defines a new IMA policy option namely "keyrings=" that
can be used to specify a set of keyrings. If this option is specified
in the policy for "measure func=KEY_CHECK" then only the keys
loaded onto a keyring given in the "keyrings=" option are measured.

If uid is specified in the policy then the key is measured only if
the current user id matches the one specified in the policy.

Added a new parameter namely "keyring" (name of the keyring) to
process_buffer_measurement(). The keyring name is passed to
ima_get_action() to determine the required action.
ima_match_rules() is updated to check keyring in the policy, if
specified, for KEY_CHECK function.

Signed-off-by: Lakshmi Ramasubramanian &lt;nramas@linux.microsoft.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>IMA: Check IMA policy flag</title>
<updated>2019-12-12T13:53:50Z</updated>
<author>
<name>Lakshmi Ramasubramanian</name>
</author>
<published>2019-12-11T16:47:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c5563bad88e07017e08cce1142903e501598c80c'/>
<id>urn:sha1:c5563bad88e07017e08cce1142903e501598c80c</id>
<content type='text'>
process_buffer_measurement() may be called prior to IMA being
initialized (for instance, when the IMA hook is called when
a key is added to the .builtin_trusted_keys keyring), which
would result in a kernel panic.

This patch adds the check in process_buffer_measurement()
to return immediately if IMA is not initialized yet.

Signed-off-by: Lakshmi Ramasubramanian &lt;nramas@linux.microsoft.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>ima: Check against blacklisted hashes for files with modsig</title>
<updated>2019-11-12T01:25:50Z</updated>
<author>
<name>Nayna Jain</name>
</author>
<published>2019-10-31T03:31:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=273df864cf7466fb170b8dcc1abd672cd08ad8d3'/>
<id>urn:sha1:273df864cf7466fb170b8dcc1abd672cd08ad8d3</id>
<content type='text'>
Asymmetric private keys are used to sign multiple files. The kernel
currently supports checking against blacklisted keys. However, if the
public key is blacklisted, any file signed by the blacklisted key will
automatically fail signature verification. Blacklisting the public key
is not fine enough granularity, as we might want to only blacklist a
particular file.

This patch adds support for checking against the blacklisted hash of
the file, without the appended signature, based on the IMA policy. It
defines a new policy option "appraise_flag=check_blacklist".

In addition to the blacklisted binary hashes stored in the firmware
"dbx" variable, the Linux kernel may be configured to load blacklisted
binary hashes onto the .blacklist keyring as well. The following
example shows how to blacklist a specific kernel module hash.

  $ sha256sum kernel/kheaders.ko
  77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3
  kernel/kheaders.ko

  $ grep BLACKLIST .config
  CONFIG_SYSTEM_BLACKLIST_KEYRING=y
  CONFIG_SYSTEM_BLACKLIST_HASH_LIST="blacklist-hash-list"

  $ cat certs/blacklist-hash-list
  "bin:77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3"

Update the IMA custom measurement and appraisal policy
rules (/etc/ima-policy):

  measure func=MODULE_CHECK template=ima-modsig
  appraise func=MODULE_CHECK appraise_flag=check_blacklist
  appraise_type=imasig|modsig

After building, installing, and rebooting the kernel:

   545660333 ---lswrv      0     0   \_ blacklist:
  bin:77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3

  measure func=MODULE_CHECK template=ima-modsig
  appraise func=MODULE_CHECK appraise_flag=check_blacklist
  appraise_type=imasig|modsig

  modprobe: ERROR: could not insert 'kheaders': Permission denied

  10 0c9834db5a0182c1fb0cdc5d3adcf11a11fd83dd ima-sig
  sha256:3bc6ed4f0b4d6e31bc1dbc9ef844605abc7afdc6d81a57d77a1ec9407997c40
  2 /usr/lib/modules/5.4.0-rc3+/kernel/kernel/kheaders.ko

  10 82aad2bcc3fa8ed94762356b5c14838f3bcfa6a0 ima-modsig
  sha256:3bc6ed4f0b4d6e31bc1dbc9ef844605abc7afdc6d81a57d77a1ec9407997c40
  2 /usr/lib/modules/5.4.0rc3+/kernel/kernel/kheaders.ko  sha256:77fa889b3
  5a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3
  3082029a06092a864886f70d010702a082028b30820287020101310d300b0609608648
  016503040201300b06092a864886f70d01070131820264....

  10 25b72217cc1152b44b134ce2cd68f12dfb71acb3 ima-buf
  sha256:8b58427fedcf8f4b20bc8dc007f2e232bf7285d7b93a66476321f9c2a3aa132
  b blacklisted-hash
  77fa889b35a05338ec52e51591c1b89d4c8d1c99a21251d7c22b1a8642a6bad3

Signed-off-by: Nayna Jain &lt;nayna@linux.ibm.com&gt;
[zohar@linux.ibm.com: updated patch description]
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/1572492694-6520-8-git-send-email-zohar@linux.ibm.com
</content>
</entry>
</feed>
