<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/security/integrity/evm/evm_main.c, branch linux-6.8.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.8.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.8.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2023-12-20T12:40:07Z</updated>
<entry>
<title>evm: add support to disable EVM on unsupported filesystems</title>
<updated>2023-12-20T12:40:07Z</updated>
<author>
<name>Mimi Zohar</name>
</author>
<published>2023-12-18T13:06:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cd708c938f055c9eb5a366ec1c8edcefa28afc28'/>
<id>urn:sha1:cd708c938f055c9eb5a366ec1c8edcefa28afc28</id>
<content type='text'>
Identify EVM unsupported filesystems by defining a new flag
SB_I_EVM_UNSUPPORTED.

Don't verify, write, remove or update 'security.evm' on unsupported
filesystems.

Acked-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
Reviewed-by: Christian Brauner &lt;brauner@kernel.org&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>evm: don't copy up 'security.evm' xattr</title>
<updated>2023-12-20T12:39:52Z</updated>
<author>
<name>Mimi Zohar</name>
</author>
<published>2023-12-12T11:12:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=40ca4ee3136d2d09977d1cab8c0c0e1582c3359d'/>
<id>urn:sha1:40ca4ee3136d2d09977d1cab8c0c0e1582c3359d</id>
<content type='text'>
The security.evm HMAC and the original file signatures contain
filesystem specific data.  As a result, the HMAC and signature
are not the same on the stacked and backing filesystems.

Don't copy up 'security.evm'.

Reviewed-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
Reviewed-by: Christian Brauner &lt;brauner@kernel.org&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>evm: Do not include crypto/algapi.h</title>
<updated>2023-09-15T10:30:43Z</updated>
<author>
<name>Herbert Xu</name>
</author>
<published>2023-08-22T09:37:13Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=aa7c98b1243773ea4a1a107d3a6b7df51ece180f'/>
<id>urn:sha1:aa7c98b1243773ea4a1a107d3a6b7df51ece180f</id>
<content type='text'>
The header file crypto/algapi.h is for internal use only.  Use the
header file crypto/utils.h instead.

Acked-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>evm: Support multiple LSMs providing an xattr</title>
<updated>2023-07-10T17:59:39Z</updated>
<author>
<name>Roberto Sassu</name>
</author>
<published>2023-06-10T07:57:38Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c31288e56c1a7bb57a1be1f9f6f3faacbeddeff6'/>
<id>urn:sha1:c31288e56c1a7bb57a1be1f9f6f3faacbeddeff6</id>
<content type='text'>
Currently, evm_inode_init_security() processes a single LSM xattr from the
array passed by security_inode_init_security(), and calculates the HMAC on
it and other inode metadata.

As the LSM infrastructure now can pass to EVM an array with multiple
xattrs, scan them until the terminator (xattr name NULL), and calculate the
HMAC on all of them.

Also, double check that the xattrs array terminator is the first non-filled
slot (obtained with lsm_get_xattr_slot()). Consumers of the xattrs array,
such as the initxattrs() callbacks, rely on the terminator.

Finally, change the name of the lsm_xattr parameter of evm_init_hmac() to
xattrs, to reflect the new type of information passed.

Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Reviewed-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Acked-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
</content>
</entry>
<entry>
<title>evm: Align evm_inode_init_security() definition with LSM infrastructure</title>
<updated>2023-07-10T17:59:38Z</updated>
<author>
<name>Roberto Sassu</name>
</author>
<published>2023-06-10T07:57:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6db7d1dee8003921b353d7e613471fe8995f46b5'/>
<id>urn:sha1:6db7d1dee8003921b353d7e613471fe8995f46b5</id>
<content type='text'>
Change the evm_inode_init_security() definition to align with the LSM
infrastructure. Keep the existing behavior of including in the HMAC
calculation only the first xattr provided by LSMs.

Changing the evm_inode_init_security() definition requires passing the
xattr array allocated by security_inode_init_security(), and the number of
xattrs filled by previously invoked LSMs.

Use the newly introduced lsm_get_xattr_slot() to position EVM correctly in
the xattrs array, like a regular LSM, and to increment the number of filled
slots. For now, the LSM infrastructure allocates enough xattrs slots to
store the EVM xattr, without using the reservation mechanism.

Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Reviewed-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Acked-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
</content>
</entry>
<entry>
<title>evm: Fix build warnings</title>
<updated>2023-06-06T12:51:11Z</updated>
<author>
<name>Roberto Sassu</name>
</author>
<published>2023-06-06T07:41:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=996e0a97ebd7b11cb785794e2a83c20c1add9d92'/>
<id>urn:sha1:996e0a97ebd7b11cb785794e2a83c20c1add9d92</id>
<content type='text'>
Fix build warnings (function parameters description) for
evm_read_protected_xattrs(), evm_set_key() and evm_verifyxattr().

Fixes: 7626676320f3 ("evm: provide a function to set the EVM key from the kernel") # v4.5+
Fixes: 8314b6732ae4 ("ima: Define new template fields xattrnames, xattrlengths and xattrvalues") # v5.14+
Fixes: 2960e6cb5f7c ("evm: additional parameter to pass integrity cache entry 'iint'") # v3.2+
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: Complete description of evm_inode_setattr()</title>
<updated>2023-06-05T13:04:41Z</updated>
<author>
<name>Roberto Sassu</name>
</author>
<published>2023-03-06T10:40:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b1de86d4248b273cb12c4cd7d20c08d459519f7d'/>
<id>urn:sha1:b1de86d4248b273cb12c4cd7d20c08d459519f7d</id>
<content type='text'>
Add the description for missing parameters of evm_inode_setattr() to
avoid the warning arising with W=n compile option.

Fixes: 817b54aa45db ("evm: add evm_inode_setattr to prevent updating an invalid security.evm") # v3.2+
Fixes: c1632a0f1120 ("fs: port -&gt;setattr() to pass mnt_idmap") # v6.3+
Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Reviewed-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>fs: port i_{g,u}id_{needs_}update() to mnt_idmap</title>
<updated>2023-01-19T08:24:29Z</updated>
<author>
<name>Christian Brauner</name>
</author>
<published>2023-01-13T11:49:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0dbe12f2e49c046444461b5f4be49df2cafb3a40'/>
<id>urn:sha1:0dbe12f2e49c046444461b5f4be49df2cafb3a40</id>
<content type='text'>
Convert to struct mnt_idmap.

Last cycle we merged the necessary infrastructure in
256c8aed2b42 ("fs: introduce dedicated idmap type for mounts").
This is just the conversion to struct mnt_idmap.

Currently we still pass around the plain namespace that was attached to a
mount. This is in general pretty convenient but it makes it easy to
conflate namespaces that are relevant on the filesystem with namespaces
that are relevent on the mount level. Especially for non-vfs developers
without detailed knowledge in this area this can be a potential source for
bugs.

Once the conversion to struct mnt_idmap is done all helpers down to the
really low-level helpers will take a struct mnt_idmap argument instead of
two namespace arguments. This way it becomes impossible to conflate the two
eliminating the possibility of any bugs. All of the vfs and all filesystems
only operate on struct mnt_idmap.

Acked-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Christian Brauner (Microsoft) &lt;brauner@kernel.org&gt;
</content>
</entry>
<entry>
<title>fs: port acl to mnt_idmap</title>
<updated>2023-01-19T08:24:28Z</updated>
<author>
<name>Christian Brauner</name>
</author>
<published>2023-01-13T11:49:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=700b7940526d31117fd20b7ed31156df134fbe7f'/>
<id>urn:sha1:700b7940526d31117fd20b7ed31156df134fbe7f</id>
<content type='text'>
Convert to struct mnt_idmap.

Last cycle we merged the necessary infrastructure in
256c8aed2b42 ("fs: introduce dedicated idmap type for mounts").
This is just the conversion to struct mnt_idmap.

Currently we still pass around the plain namespace that was attached to a
mount. This is in general pretty convenient but it makes it easy to
conflate namespaces that are relevant on the filesystem with namespaces
that are relevent on the mount level. Especially for non-vfs developers
without detailed knowledge in this area this can be a potential source for
bugs.

Once the conversion to struct mnt_idmap is done all helpers down to the
really low-level helpers will take a struct mnt_idmap argument instead of
two namespace arguments. This way it becomes impossible to conflate the two
eliminating the possibility of any bugs. All of the vfs and all filesystems
only operate on struct mnt_idmap.

Acked-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Christian Brauner (Microsoft) &lt;brauner@kernel.org&gt;
</content>
</entry>
<entry>
<title>fs: port xattr to mnt_idmap</title>
<updated>2023-01-19T08:24:28Z</updated>
<author>
<name>Christian Brauner</name>
</author>
<published>2023-01-13T11:49:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=39f60c1ccee72caa0104145b5dbf5d37cce1ea39'/>
<id>urn:sha1:39f60c1ccee72caa0104145b5dbf5d37cce1ea39</id>
<content type='text'>
Convert to struct mnt_idmap.

Last cycle we merged the necessary infrastructure in
256c8aed2b42 ("fs: introduce dedicated idmap type for mounts").
This is just the conversion to struct mnt_idmap.

Currently we still pass around the plain namespace that was attached to a
mount. This is in general pretty convenient but it makes it easy to
conflate namespaces that are relevant on the filesystem with namespaces
that are relevent on the mount level. Especially for non-vfs developers
without detailed knowledge in this area this can be a potential source for
bugs.

Once the conversion to struct mnt_idmap is done all helpers down to the
really low-level helpers will take a struct mnt_idmap argument instead of
two namespace arguments. This way it becomes impossible to conflate the two
eliminating the possibility of any bugs. All of the vfs and all filesystems
only operate on struct mnt_idmap.

Acked-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Christian Brauner (Microsoft) &lt;brauner@kernel.org&gt;
</content>
</entry>
</feed>
