This patch set depends on:
https://lore.kernel.org/linux-integrity/[email protected]/
https://lore.kernel.org/linux-integrity/[email protected]/
One of the challenges that must be tackled to move IMA and EVM to the LSM
infrastructure is to ensure that EVM is capable to correctly handle
multiple stacked LSMs providing an xattr at file creation. At the moment,
there are few issues that would prevent a correct integration. This patch
set aims at solving them.
From the LSM infrastructure side, the LSM stacking feature added the
possibility of registering multiple implementations of the security hooks,
that are called sequentially whenever someone calls the corresponding
security hook. However, security_inode_init_security() and
security_old_inode_init_security() are currently limited to support one
xattr provided by LSM and one by EVM.
In addition, using the call_int_hook() macro causes some issues. According
to the documentation in include/linux/lsm_hooks.h, it is a legitimate case
that an LSM returns -EOPNOTSUPP when it does not want to provide an xattr.
However, the loop defined in the macro would stop calling subsequent LSMs
if that happens. In the case of security_old_inode_init_security(), using
the macro would also cause a memory leak due to replacing the *value
pointer, if multiple LSMs provide an xattr.
From EVM side, the first operation to be done is to change the definition
of evm_inode_init_security() to be compatible with the security hook
definition. Unfortunately, the current definition does not provide enough
information for EVM, as it must have visibility of all xattrs provided by
LSMs to correctly calculate the HMAC. This patch set changes the security
hook definition by adding the full array of xattr as a parameter.
Secondly, EVM must know how many elements are in the xattr array. It seems
that it is not necessary to add another parameter, as all filesystems that
define an initxattr function, expect that the last element of the array is
one with the name field set to NULL. EVM reuses the same assumption.
This patch set has been tested by introducing several instances of a
TestLSM (some providing an xattr, some not, one with a wrong implementation
to see how the LSM infrastructure handles it). The patch is not included
in this set but it is available here:
https://github.com/robertosassu/linux/commit/0370ff0fbc16e5d63489836a958e65d697f956db
The test, added to ima-evm-utils, is available here:
https://github.com/robertosassu/ima-evm-utils/blob/evm-multiple-lsms-v1-devel-v1/tests/evm_multiple_lsms.test
The test takes a UML kernel built by Travis and launches it several times,
each time with a different combination of LSMs. After boot, it first checks
that there is an xattr for each LSM providing it, and then calculates the
HMAC in user space and compares it with the HMAC calculated by EVM in
kernel space.
A test report can be obtained here:
https://www.travis-ci.com/github/robertosassu/ima-evm-utils/jobs/498699540
Lastly, running the test on reiserfs to check
security_old_inode_init_security(), some issues have been discovered: a
free of xattr->name which is not correct after commit 9548906b2bb7 ('xattr:
Constify ->name member of "struct xattr"'), and a misalignment with
security_inode_init_security() (the old version expects the full xattr name
with the security. prefix, the new version just the suffix). The last issue
has not been fixed yet.
Roberto Sassu (5):
xattr: Complete constify ->name member of "struct xattr"
security: Support multiple LSMs implementing the inode_init_security
hook
security: Pass xattrs allocated by LSMs to the inode_init_security
hook
evm: Align evm_inode_init_security() definition with LSM
infrastructure
evm: Support multiple LSMs providing an xattr
fs/reiserfs/xattr_security.c | 2 -
include/linux/evm.h | 21 ++++---
include/linux/lsm_hook_defs.h | 2 +-
include/linux/lsm_hooks.h | 5 +-
security/integrity/evm/evm.h | 2 +
security/integrity/evm/evm_crypto.c | 9 ++-
security/integrity/evm/evm_main.c | 35 +++++++----
security/security.c | 95 +++++++++++++++++++++++------
security/selinux/hooks.c | 3 +-
security/smack/smack_lsm.c | 4 +-
10 files changed, 135 insertions(+), 43 deletions(-)
--
2.26.2
This patch changes the evm_inode_init_security() definition to align with
the LSM infrastructure, in preparation for moving IMA and EVM to that
infrastructure.
Signed-off-by: Roberto Sassu <[email protected]>
---
include/linux/evm.h | 21 ++++++++++++++-------
security/integrity/evm/evm_main.c | 24 +++++++++++++++---------
security/security.c | 7 +++++--
3 files changed, 34 insertions(+), 18 deletions(-)
diff --git a/include/linux/evm.h b/include/linux/evm.h
index 8cad46bcec9d..5d8b29d80296 100644
--- a/include/linux/evm.h
+++ b/include/linux/evm.h
@@ -34,9 +34,11 @@ extern int evm_inode_removexattr(struct user_namespace *mnt_userns,
struct dentry *dentry, const char *xattr_name);
extern void evm_inode_post_removexattr(struct dentry *dentry,
const char *xattr_name);
-extern int evm_inode_init_security(struct inode *inode,
- const struct xattr *xattr_array,
- struct xattr *evm);
+extern int evm_inode_init_security(struct inode *inode, struct inode *dir,
+ const struct qstr *qstr,
+ const char **name,
+ void **value, size_t *len,
+ struct xattr *lsm_xattrs);
extern bool evm_status_revalidate(const char *xattr_name);
#ifdef CONFIG_FS_POSIX_ACL
extern int posix_xattr_acl(const char *xattrname);
@@ -102,11 +104,16 @@ static inline void evm_inode_post_removexattr(struct dentry *dentry,
return;
}
-static inline int evm_inode_init_security(struct inode *inode,
- const struct xattr *xattr_array,
- struct xattr *evm)
+static inline int evm_inode_init_security(struct inode *inode, struct inode *dir,
+ const struct qstr *qstr,
+ const char **name,
+ void **value, size_t *len,
+ struct xattr *lsm_xattrs)
{
- return 0;
+ if (!name || !value || !len || !lsm_xattrs)
+ return 0;
+
+ return -EOPNOTSUPP;
}
static inline bool evm_status_revalidate(const char *xattr_name)
diff --git a/security/integrity/evm/evm_main.c b/security/integrity/evm/evm_main.c
index 84a9b7a69b1f..a5069d69a893 100644
--- a/security/integrity/evm/evm_main.c
+++ b/security/integrity/evm/evm_main.c
@@ -706,29 +706,35 @@ void evm_inode_post_setattr(struct dentry *dentry, int ia_valid)
/*
* evm_inode_init_security - initializes security.evm HMAC value
*/
-int evm_inode_init_security(struct inode *inode,
- const struct xattr *lsm_xattr,
- struct xattr *evm_xattr)
+int evm_inode_init_security(struct inode *inode, struct inode *dir,
+ const struct qstr *qstr,
+ const char **name,
+ void **value, size_t *len,
+ struct xattr *lsm_xattrs)
{
struct evm_xattr *xattr_data;
int rc;
- if (!(evm_initialized & EVM_INIT_HMAC) ||
- !evm_protected_xattr(lsm_xattr->name))
+ if (!name || !value || !len || !lsm_xattrs)
return 0;
+ if (!(evm_initialized & EVM_INIT_HMAC) ||
+ !evm_protected_xattr(lsm_xattrs->name))
+ return -EOPNOTSUPP;
+
xattr_data = kzalloc(sizeof(*xattr_data), GFP_NOFS);
if (!xattr_data)
return -ENOMEM;
xattr_data->data.type = EVM_XATTR_HMAC;
- rc = evm_init_hmac(inode, lsm_xattr, xattr_data->digest);
+ rc = evm_init_hmac(inode, lsm_xattrs, xattr_data->digest);
if (rc < 0)
goto out;
- evm_xattr->value = xattr_data;
- evm_xattr->value_len = hash_digest_size[evm_hash_algo] + 1;
- evm_xattr->name = XATTR_EVM_SUFFIX;
+ *name = XATTR_EVM_SUFFIX;
+ *value = xattr_data;
+ *len = hash_digest_size[evm_hash_algo] + 1;
+
return 0;
out:
kfree(xattr_data);
diff --git a/security/security.c b/security/security.c
index 8aabbc0f0dfc..e16ce150b111 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1080,8 +1080,11 @@ int security_inode_init_security(struct inode *inode, struct inode *dir,
goto out;
}
- ret = evm_inode_init_security(inode, new_xattrs, lsm_xattr);
- if (ret)
+ ret = evm_inode_init_security(inode, dir, qstr,
+ &lsm_xattr->name,
+ &lsm_xattr->value,
+ &lsm_xattr->value_len, new_xattrs);
+ if (ret && ret != -EOPNOTSUPP)
goto out;
ret = initxattrs(inode, new_xattrs, fs_data);
out:
--
2.26.2
The current implementation of security_inode_init_security() is capable of
handling only one LSM providing an xattr to be set at inode creation. That
xattr is then passed to EVM to calculate the HMAC.
To support multiple LSMs, each providing an xattr, this patch makes the
following modifications:
security_inode_init_security():
- dynamically allocates new_xattrs, based on the number of
inode_init_security hooks registered by LSMs;
- replaces the call_int_hook() macro with its definition, to correctly
handle the case of an LSM returning -EOPNOTSUPP (the loop should not be
stopped), and to advance in the new_xattrs array so that the correct
xattr name, value and len pointers are passed to LSMs.
security_old_inode_init_security():
- replaces the call_int_hook() macro with its definition, to stop the loop
at the first LSM providing an xattr, to avoid a memory leak (due to
overwriting the *value pointer).
The modifications necessary for EVM to calculate the HMAC on all xattrs
will be done in a separate patch.
Signed-off-by: Roberto Sassu <[email protected]>
---
security/security.c | 87 +++++++++++++++++++++++++++++++++++++--------
1 file changed, 72 insertions(+), 15 deletions(-)
diff --git a/security/security.c b/security/security.c
index 7f14e59c4f8e..65624357b335 100644
--- a/security/security.c
+++ b/security/security.c
@@ -30,8 +30,6 @@
#include <linux/msg.h>
#include <net/flow.h>
-#define MAX_LSM_EVM_XATTR 2
-
/* How many LSMs were built into the kernel? */
#define LSM_COUNT (__end_lsm_info - __start_lsm_info)
@@ -1028,9 +1026,10 @@ int security_inode_init_security(struct inode *inode, struct inode *dir,
const struct qstr *qstr,
const initxattrs initxattrs, void *fs_data)
{
- struct xattr new_xattrs[MAX_LSM_EVM_XATTR + 1];
- struct xattr *lsm_xattr, *evm_xattr, *xattr;
- int ret;
+ struct xattr *new_xattrs;
+ struct xattr *lsm_xattr, *xattr;
+ struct security_hook_list *P;
+ int ret, max_new_xattrs = 0;
if (unlikely(IS_PRIVATE(inode)))
return 0;
@@ -1038,23 +1037,56 @@ int security_inode_init_security(struct inode *inode, struct inode *dir,
if (!initxattrs)
return call_int_hook(inode_init_security, -EOPNOTSUPP, inode,
dir, qstr, NULL, NULL, NULL);
- memset(new_xattrs, 0, sizeof(new_xattrs));
+
+ /* Determine at run-time the max number of xattr structs to allocate. */
+ hlist_for_each_entry(P, &security_hook_heads.inode_init_security, list)
+ max_new_xattrs++;
+
+ if (!max_new_xattrs)
+ return 0;
+
+ /* Allocate +1 for EVM and +1 as terminator. */
+ new_xattrs = kcalloc(max_new_xattrs + 2, sizeof(*new_xattrs), GFP_NOFS);
+ if (!new_xattrs)
+ return -ENOMEM;
+
lsm_xattr = new_xattrs;
- ret = call_int_hook(inode_init_security, -EOPNOTSUPP, inode, dir, qstr,
- &lsm_xattr->name,
- &lsm_xattr->value,
- &lsm_xattr->value_len);
- if (ret)
+ hlist_for_each_entry(P, &security_hook_heads.inode_init_security,
+ list) {
+ ret = P->hook.inode_init_security(inode, dir, qstr,
+ &lsm_xattr->name,
+ &lsm_xattr->value,
+ &lsm_xattr->value_len);
+ if (ret && ret != -EOPNOTSUPP)
+ goto out;
+
+ /* LSM implementation error. */
+ if (!ret &&
+ (lsm_xattr->name == NULL || lsm_xattr->value == NULL)) {
+ WARN_ONCE(
+ "LSM %s: ret = 0 but xattr name/value = NULL\n",
+ P->lsm);
+ ret = -ENOENT;
+ goto out;
+ }
+
+ if (!ret && lsm_xattr < new_xattrs + max_new_xattrs)
+ lsm_xattr++;
+ }
+
+ if (lsm_xattr == new_xattrs) {
+ ret = -EOPNOTSUPP;
goto out;
+ }
- evm_xattr = lsm_xattr + 1;
- ret = evm_inode_init_security(inode, lsm_xattr, evm_xattr);
+ ret = evm_inode_init_security(inode, new_xattrs, lsm_xattr);
if (ret)
goto out;
ret = initxattrs(inode, new_xattrs, fs_data);
out:
for (xattr = new_xattrs; xattr->value != NULL; xattr++)
kfree(xattr->value);
+ kfree(new_xattrs);
return (ret == -EOPNOTSUPP) ? 0 : ret;
}
EXPORT_SYMBOL(security_inode_init_security);
@@ -1071,10 +1103,35 @@ int security_old_inode_init_security(struct inode *inode, struct inode *dir,
const struct qstr *qstr, const char **name,
void **value, size_t *len)
{
+ struct security_hook_list *P;
+ int ret;
+
if (unlikely(IS_PRIVATE(inode)))
return -EOPNOTSUPP;
- return call_int_hook(inode_init_security, -EOPNOTSUPP, inode, dir,
- qstr, name, value, len);
+
+ hlist_for_each_entry(P, &security_hook_heads.inode_init_security,
+ list) {
+ ret = P->hook.inode_init_security(inode, dir, qstr,
+ name, value, len);
+ if (ret && ret != -EOPNOTSUPP)
+ return ret;
+
+ /* LSM implementation error. */
+ if (!ret &&
+ ((name && *name == NULL) || (value && *value == NULL))) {
+ WARN_ONCE(
+ "LSM %s: ret = 0 but xattr name/value = NULL\n",
+ P->lsm);
+
+ /* Callers should do the cleanup. */
+ return -ENOENT;
+ }
+
+ if (!ret)
+ return ret;
+ }
+
+ return -EOPNOTSUPP;
}
EXPORT_SYMBOL(security_old_inode_init_security);
--
2.26.2
In preparation for moving EVM to the LSM infrastructure, this patch adds
the full array of xattrs allocated by LSMs as a new parameter of the
inode_init_security hook. It will be used by EVM to calculate the HMAC on
all xattrs.
This solution has been preferred to directly replacing the xattr name,
value and len with the full array, as LSMs would have had to scan it to
find an empty slot.
Signed-off-by: Roberto Sassu <[email protected]>
---
include/linux/lsm_hook_defs.h | 2 +-
include/linux/lsm_hooks.h | 1 +
security/security.c | 7 ++++---
security/selinux/hooks.c | 3 ++-
security/smack/smack_lsm.c | 4 +++-
5 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index 477a597db013..45a0b8cbb974 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -112,7 +112,7 @@ LSM_HOOK(int, 0, inode_alloc_security, struct inode *inode)
LSM_HOOK(void, LSM_RET_VOID, inode_free_security, struct inode *inode)
LSM_HOOK(int, 0, inode_init_security, struct inode *inode,
struct inode *dir, const struct qstr *qstr, const char **name,
- void **value, size_t *len)
+ void **value, size_t *len, struct xattr *lsm_xattrs)
LSM_HOOK(int, 0, inode_init_security_anon, struct inode *inode,
const struct qstr *name, const struct inode *context_inode)
LSM_HOOK(int, 0, inode_create, struct inode *dir, struct dentry *dentry,
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index c5498f5174ce..1dd79e2f02ad 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -230,6 +230,7 @@
* @name will be set to the allocated name suffix (e.g. selinux).
* @value will be set to the allocated attribute value.
* @len will be set to the length of the value.
+ * @lsm_xattrs contains the full array of xattrs allocated by LSMs.
* Returns 0 if @name and @value have been successfully set,
* -EOPNOTSUPP if no security attribute is needed, or
* -ENOMEM on memory allocation failure.
diff --git a/security/security.c b/security/security.c
index 65624357b335..8aabbc0f0dfc 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1036,7 +1036,7 @@ int security_inode_init_security(struct inode *inode, struct inode *dir,
if (!initxattrs)
return call_int_hook(inode_init_security, -EOPNOTSUPP, inode,
- dir, qstr, NULL, NULL, NULL);
+ dir, qstr, NULL, NULL, NULL, NULL);
/* Determine at run-time the max number of xattr structs to allocate. */
hlist_for_each_entry(P, &security_hook_heads.inode_init_security, list)
@@ -1056,7 +1056,8 @@ int security_inode_init_security(struct inode *inode, struct inode *dir,
ret = P->hook.inode_init_security(inode, dir, qstr,
&lsm_xattr->name,
&lsm_xattr->value,
- &lsm_xattr->value_len);
+ &lsm_xattr->value_len,
+ new_xattrs);
if (ret && ret != -EOPNOTSUPP)
goto out;
@@ -1112,7 +1113,7 @@ int security_old_inode_init_security(struct inode *inode, struct inode *dir,
hlist_for_each_entry(P, &security_hook_heads.inode_init_security,
list) {
ret = P->hook.inode_init_security(inode, dir, qstr,
- name, value, len);
+ name, value, len, NULL);
if (ret && ret != -EOPNOTSUPP)
return ret;
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index ddd097790d47..2fe9c39414d0 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2917,7 +2917,8 @@ static int selinux_dentry_create_files_as(struct dentry *dentry, int mode,
static int selinux_inode_init_security(struct inode *inode, struct inode *dir,
const struct qstr *qstr,
const char **name,
- void **value, size_t *len)
+ void **value, size_t *len,
+ struct xattr *lsm_xattrs)
{
const struct task_security_struct *tsec = selinux_cred(current_cred());
struct superblock_security_struct *sbsec;
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 12a45e61c1a5..9d562ea576ca 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -965,12 +965,14 @@ static int smack_inode_alloc_security(struct inode *inode)
* @name: where to put the attribute name
* @value: where to put the attribute value
* @len: where to put the length of the attribute
+ * @lsm_xattrs: unused
*
* Returns 0 if it all works out, -ENOMEM if there's no memory
*/
static int smack_inode_init_security(struct inode *inode, struct inode *dir,
const struct qstr *qstr, const char **name,
- void **value, size_t *len)
+ void **value, size_t *len,
+ struct xattr *lsm_xattrs)
{
struct inode_smack *issp = smack_inode(inode);
struct smack_known *skp = smk_of_current();
--
2.26.2
Currently, evm_inode_init_security() takes as input a single LSM xattr,
passed by security_inode_init_security(), and calculates the HMAC on it and
other inode metadata.
Given that initxattrs(), called by security_inode_init_security(), expects
that this array is terminated when the xattr name is set to NULL, this
patch reuses the same assumption for evm_inode_init_security() to scan all
xattrs and to calculate the HMAC on all of them.
Signed-off-by: Roberto Sassu <[email protected]>
---
security/integrity/evm/evm.h | 2 ++
security/integrity/evm/evm_crypto.c | 9 ++++++++-
security/integrity/evm/evm_main.c | 15 +++++++++++----
3 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/security/integrity/evm/evm.h b/security/integrity/evm/evm.h
index ae590f71ce7d..24eac42b9f32 100644
--- a/security/integrity/evm/evm.h
+++ b/security/integrity/evm/evm.h
@@ -49,6 +49,8 @@ struct evm_digest {
char digest[IMA_MAX_DIGEST_SIZE];
} __packed;
+int evm_protected_xattr(const char *req_xattr_name);
+
int evm_init_key(void);
int __init evm_init_crypto(void);
int evm_update_evmxattr(struct dentry *dentry,
diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
index b66264b53d5d..35c5eec0517d 100644
--- a/security/integrity/evm/evm_crypto.c
+++ b/security/integrity/evm/evm_crypto.c
@@ -358,6 +358,7 @@ int evm_init_hmac(struct inode *inode, const struct xattr *lsm_xattr,
char *hmac_val)
{
struct shash_desc *desc;
+ const struct xattr *xattr;
desc = init_desc(EVM_XATTR_HMAC, evm_hash_algo);
if (IS_ERR(desc)) {
@@ -365,7 +366,13 @@ int evm_init_hmac(struct inode *inode, const struct xattr *lsm_xattr,
return PTR_ERR(desc);
}
- crypto_shash_update(desc, lsm_xattr->value, lsm_xattr->value_len);
+ for (xattr = lsm_xattr; xattr->name != NULL; xattr++) {
+ if (!evm_protected_xattr(xattr->name))
+ continue;
+
+ crypto_shash_update(desc, xattr->value, xattr->value_len);
+ }
+
hmac_add_misc(desc, inode, EVM_XATTR_HMAC, hmac_val);
kfree(desc);
return 0;
diff --git a/security/integrity/evm/evm_main.c b/security/integrity/evm/evm_main.c
index a5069d69a893..fde366149499 100644
--- a/security/integrity/evm/evm_main.c
+++ b/security/integrity/evm/evm_main.c
@@ -260,7 +260,7 @@ static enum integrity_status evm_verify_hmac(struct dentry *dentry,
return evm_status;
}
-static int evm_protected_xattr(const char *req_xattr_name)
+int evm_protected_xattr(const char *req_xattr_name)
{
int namelen;
int found = 0;
@@ -712,14 +712,21 @@ int evm_inode_init_security(struct inode *inode, struct inode *dir,
void **value, size_t *len,
struct xattr *lsm_xattrs)
{
+ struct xattr *xattr;
struct evm_xattr *xattr_data;
- int rc;
+ int rc, evm_protected_xattrs = 0;
if (!name || !value || !len || !lsm_xattrs)
return 0;
- if (!(evm_initialized & EVM_INIT_HMAC) ||
- !evm_protected_xattr(lsm_xattrs->name))
+ if (!(evm_initialized & EVM_INIT_HMAC))
+ return -EOPNOTSUPP;
+
+ for (xattr = lsm_xattrs; xattr && xattr->name != NULL; xattr++)
+ if (evm_protected_xattr(xattr->name))
+ evm_protected_xattrs++;
+
+ if (!evm_protected_xattrs)
return -EOPNOTSUPP;
xattr_data = kzalloc(sizeof(*xattr_data), GFP_NOFS);
--
2.26.2
On 4/15/2021 3:04 AM, Roberto Sassu wrote:
> This patch set depends on:
>
> https://lore.kernel.org/linux-integrity/[email protected]/
> https://lore.kernel.org/linux-integrity/[email protected]/
>
> One of the challenges that must be tackled to move IMA and EVM to the LSM
> infrastructure is to ensure that EVM is capable to correctly handle
> multiple stacked LSMs providing an xattr at file creation. At the moment,
> there are few issues that would prevent a correct integration. This patch
> set aims at solving them.
>
> From the LSM infrastructure side, the LSM stacking feature added the
> possibility of registering multiple implementations of the security hooks,
> that are called sequentially whenever someone calls the corresponding
> security hook. However, security_inode_init_security() and
> security_old_inode_init_security() are currently limited to support one
> xattr provided by LSM and one by EVM.
That is correct. At present the only two modules that provide extended
attributes are SELinux and Smack. The LSM infrastructure requires more
change, including change to security_inode_init_security(), before those
modules can be used together.
> In addition, using the call_int_hook() macro causes some issues. According
> to the documentation in include/linux/lsm_hooks.h, it is a legitimate case
> that an LSM returns -EOPNOTSUPP when it does not want to provide an xattr.
> However, the loop defined in the macro would stop calling subsequent LSMs
> if that happens. In the case of security_old_inode_init_security(), using
> the macro would also cause a memory leak due to replacing the *value
> pointer, if multiple LSMs provide an xattr.
As there is no case where there will be multiple providers of hooks for
inode_init_security this isn't an issue.
> From EVM side, the first operation to be done is to change the definition
> of evm_inode_init_security() to be compatible with the security hook
> definition. Unfortunately, the current definition does not provide enough
> information for EVM, as it must have visibility of all xattrs provided by
> LSMs to correctly calculate the HMAC. This patch set changes the security
> hook definition by adding the full array of xattr as a parameter.
Why do you want to call evm_inode_init_security() as a regular LSM hook?
Except for the names evm_inode_init_security() and selinux_inode_init_security()
have nothing in common. They do very different things and require different
data, as comes out in the patches.
There are evm functions that could be implemented as LSM hooks. I don't think
this is one of them. There's no point in going overboard.
> Secondly, EVM must know how many elements are in the xattr array. It seems
> that it is not necessary to add another parameter, as all filesystems that
> define an initxattr function, expect that the last element of the array
is
> one with the name field set to NULL. EVM reuses the same assumption.
>
> This patch set has been tested by introducing several instances of a
> TestLSM (some providing an xattr, some not, one with a wrong implementation
> to see how the LSM infrastructure handles it). The patch is not included
> in this set but it is available here:
>
> https://github.com/robertosassu/linux/commit/0370ff0fbc16e5d63489836a958e65d697f956db
>
> The test, added to ima-evm-utils, is available here:
>
> https://github.com/robertosassu/ima-evm-utils/blob/evm-multiple-lsms-v1-devel-v1/tests/evm_multiple_lsms.test
>
> The test takes a UML kernel built by Travis and launches it several times,
> each time with a different combination of LSMs. After boot, it first checks
> that there is an xattr for each LSM providing it, and then calculates the
> HMAC in user space and compares it with the HMAC calculated by EVM in
> kernel space.
>
> A test report can be obtained here:
>
> https://www.travis-ci.com/github/robertosassu/ima-evm-utils/jobs/498699540
>
> Lastly, running the test on reiserfs to check
> security_old_inode_init_security(), some issues have been discovered: a
> free of xattr->name which is not correct after commit 9548906b2bb7 ('xattr:
> Constify ->name member of "struct xattr"'), and a misalignment with
> security_inode_init_security() (the old version expects the full xattr name
> with the security. prefix, the new version just the suffix). The last issue
> has not been fixed yet.
>
> Roberto Sassu (5):
> xattr: Complete constify ->name member of "struct xattr"
> security: Support multiple LSMs implementing the inode_init_security
> hook
> security: Pass xattrs allocated by LSMs to the inode_init_security
> hook
> evm: Align evm_inode_init_security() definition with LSM
> infrastructure
> evm: Support multiple LSMs providing an xattr
>
> fs/reiserfs/xattr_security.c | 2 -
> include/linux/evm.h | 21 ++++---
> include/linux/lsm_hook_defs.h | 2 +-
> include/linux/lsm_hooks.h | 5 +-
> security/integrity/evm/evm.h | 2 +
> security/integrity/evm/evm_crypto.c | 9 ++-
> security/integrity/evm/evm_main.c | 35 +++++++----
> security/security.c | 95 +++++++++++++++++++++++------
> security/selinux/hooks.c | 3 +-
> security/smack/smack_lsm.c | 4 +-
> 10 files changed, 135 insertions(+), 43 deletions(-)
>
> From: Casey Schaufler [mailto:[email protected]]
> Sent: Thursday, April 15, 2021 10:44 PM
> On 4/15/2021 3:04 AM, Roberto Sassu wrote:
> > This patch set depends on:
> >
> > https://lore.kernel.org/linux-integrity/20210409114313.4073-1-
> [email protected]/
> > https://lore.kernel.org/linux-integrity/20210407105252.30721-1-
> [email protected]/
> >
> > One of the challenges that must be tackled to move IMA and EVM to the LSM
> > infrastructure is to ensure that EVM is capable to correctly handle
> > multiple stacked LSMs providing an xattr at file creation. At the moment,
> > there are few issues that would prevent a correct integration. This patch
> > set aims at solving them.
> >
> > From the LSM infrastructure side, the LSM stacking feature added the
> > possibility of registering multiple implementations of the security hooks,
> > that are called sequentially whenever someone calls the corresponding
> > security hook. However, security_inode_init_security() and
> > security_old_inode_init_security() are currently limited to support one
> > xattr provided by LSM and one by EVM.
>
> That is correct. At present the only two modules that provide extended
> attributes are SELinux and Smack. The LSM infrastructure requires more
> change, including change to security_inode_init_security(), before those
> modules can be used together.
One of the goals of this patch set is to solve the specific problem
of security_inode_init_security(), when arbitrary LSMs are added
to the LSM infrastructure. Given that some problems have
been already identified, and will arise when a new LSM
providing an implementation for the inode_init_security hook
will be added to the LSM infrastructure, it seems a good idea
fixing them. We could discuss about the solution, if there is
a better approach.
> > In addition, using the call_int_hook() macro causes some issues. According
> > to the documentation in include/linux/lsm_hooks.h, it is a legitimate case
> > that an LSM returns -EOPNOTSUPP when it does not want to provide an xattr.
> > However, the loop defined in the macro would stop calling subsequent LSMs
> > if that happens. In the case of security_old_inode_init_security(), using
> > the macro would also cause a memory leak due to replacing the *value
> > pointer, if multiple LSMs provide an xattr.
>
> As there is no case where there will be multiple providers of hooks for
> inode_init_security this isn't an issue.
I could skip the patches that are not required to support
multiple LSMs registering to the inode_init_security hook
and just do the EVM changes (see below for the motivation).
> > From EVM side, the first operation to be done is to change the definition
> > of evm_inode_init_security() to be compatible with the security hook
> > definition. Unfortunately, the current definition does not provide enough
> > information for EVM, as it must have visibility of all xattrs provided by
> > LSMs to correctly calculate the HMAC. This patch set changes the security
> > hook definition by adding the full array of xattr as a parameter.
>
> Why do you want to call evm_inode_init_security() as a regular LSM hook?
> Except for the names evm_inode_init_security() and
> selinux_inode_init_security()
> have nothing in common. They do very different things and require different
> data, as comes out in the patches.
I thought that it would be more clean if all hooks are registered
to the LSM infrastructure. Otherwise, it could happen that some
hooks are still executed even if the LSM is not active, from the
perspective of the LSM infrastructure.
evm_inode_init_security() is still a provider of xattrs, like the
other LSMs, just it requires an extra parameter to calculate
the HMAC.
> There are evm functions that could be implemented as LSM hooks. I don't think
> this is one of them. There's no point in going overboard.
IMA and EVM both use a cache to store the integrity verification,
which is currently not managed by the LSM infrastructure but
by an ad-hoc mechanism implemented with an rbtree.
One of the benefits of defining both IMA and EVM as an LSM
is that we can switch from this ad-hoc mechanism to the one
implemented for the LSM infrastructure, with a search in
constant time. Given that evm_inode_init_security() would
update the integrity status (xattrs are good at inode creation
time), I would add it as well to the LSM infrastructure.
One additional motivation for defining EVM as an LSM is that
it would solve one of the EVM limitations that affects its
usability: partial copy of xattrs (e.g. by cp and tar) would not
work when an HMAC key is loaded because, since EVM in
the post set/removexattr hook does not know the status
of the last integrity verification, it has to deny the permission
to perform the xattr operation, to avoid that the HMAC is
calculated on corrupted xattrs. Having the status in the
per-inode blob would solve this issue more efficiently than
adding a cache for each verified inode in the rbtree.
Would you see this as an useful modification?
Thanks
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli
> > Secondly, EVM must know how many elements are in the xattr array. It
> seems
> > that it is not necessary to add another parameter, as all filesystems that
> > define an initxattr function, expect that the last element of the array
> is
> > one with the name field set to NULL. EVM reuses the same assumption.
> >
> > This patch set has been tested by introducing several instances of a
> > TestLSM (some providing an xattr, some not, one with a wrong
> implementation
> > to see how the LSM infrastructure handles it). The patch is not included
> > in this set but it is available here:
> >
> >
> https://github.com/robertosassu/linux/commit/0370ff0fbc16e5d63489836a95
> 8e65d697f956db
> >
> > The test, added to ima-evm-utils, is available here:
> >
> > https://github.com/robertosassu/ima-evm-utils/blob/evm-multiple-lsms-v1-
> devel-v1/tests/evm_multiple_lsms.test
> >
> > The test takes a UML kernel built by Travis and launches it several times,
> > each time with a different combination of LSMs. After boot, it first checks
> > that there is an xattr for each LSM providing it, and then calculates the
> > HMAC in user space and compares it with the HMAC calculated by EVM in
> > kernel space.
> >
> > A test report can be obtained here:
> >
> > https://www.travis-ci.com/github/robertosassu/ima-evm-
> utils/jobs/498699540
> >
> > Lastly, running the test on reiserfs to check
> > security_old_inode_init_security(), some issues have been discovered: a
> > free of xattr->name which is not correct after commit 9548906b2bb7 ('xattr:
> > Constify ->name member of "struct xattr"'), and a misalignment with
> > security_inode_init_security() (the old version expects the full xattr name
> > with the security. prefix, the new version just the suffix). The last issue
> > has not been fixed yet.
> >
> > Roberto Sassu (5):
> > xattr: Complete constify ->name member of "struct xattr"
> > security: Support multiple LSMs implementing the inode_init_security
> > hook
> > security: Pass xattrs allocated by LSMs to the inode_init_security
> > hook
> > evm: Align evm_inode_init_security() definition with LSM
> > infrastructure
> > evm: Support multiple LSMs providing an xattr
> >
> > fs/reiserfs/xattr_security.c | 2 -
> > include/linux/evm.h | 21 ++++---
> > include/linux/lsm_hook_defs.h | 2 +-
> > include/linux/lsm_hooks.h | 5 +-
> > security/integrity/evm/evm.h | 2 +
> > security/integrity/evm/evm_crypto.c | 9 ++-
> > security/integrity/evm/evm_main.c | 35 +++++++----
> > security/security.c | 95 +++++++++++++++++++++++------
> > security/selinux/hooks.c | 3 +-
> > security/smack/smack_lsm.c | 4 +-
> > 10 files changed, 135 insertions(+), 43 deletions(-)
> >
On 4/16/2021 9:37 AM, Roberto Sassu wrote:
>> From: Casey Schaufler [mailto:[email protected]]
>> Sent: Thursday, April 15, 2021 10:44 PM
>> On 4/15/2021 3:04 AM, Roberto Sassu wrote:
>>> This patch set depends on:
>>>
>>> https://lore.kernel.org/linux-integrity/20210409114313.4073-1-
>> [email protected]/
>>> https://lore.kernel.org/linux-integrity/20210407105252.30721-1-
>> [email protected]/
>>> One of the challenges that must be tackled to move IMA and EVM to the
LSM
>>> infrastructure is to ensure that EVM is capable to correctly handle
>>> multiple stacked LSMs providing an xattr at file creation. At the moment,
>>> there are few issues that would prevent a correct integration. This patch
>>> set aims at solving them.
>>>
>>> From the LSM infrastructure side, the LSM stacking feature added the
>>> possibility of registering multiple implementations of the security hooks,
>>> that are called sequentially whenever someone calls the corresponding
>>> security hook. However, security_inode_init_security() and
>>> security_old_inode_init_security() are currently limited to support one
>>> xattr provided by LSM and one by EVM.
>> That is correct. At present the only two modules that provide extended
>> attributes are SELinux and Smack. The LSM infrastructure requires more
>> change, including change to security_inode_init_security(), before those
>> modules can be used together.
> One of the goals of this patch set is to solve the specific problem
> of security_inode_init_security(), when arbitrary LSMs are added
> to the LSM infrastructure. Given that some problems have
> been already identified, and will arise when a new LSM
> providing an implementation for the inode_init_security hook
> will be added to the LSM infrastructure, it seems a good idea
> fixing them. We could discuss about the solution, if there is
> a better approach.
>
>>> In addition, using the call_int_hook() macro causes some issues. According
>>> to the documentation in include/linux/lsm_hooks.h, it is a legitimate
case
>>> that an LSM returns -EOPNOTSUPP when it does not want to provide an xattr.
>>> However, the loop defined in the macro would stop calling subsequent LSMs
>>> if that happens. In the case of security_old_inode_init_security(), using
>>> the macro would also cause a memory leak due to replacing the *value
>>> pointer, if multiple LSMs provide an xattr.
>> As there is no case where there will be multiple providers of hooks for
>> inode_init_security this isn't an issue.
> I could skip the patches that are not required to support
> multiple LSMs registering to the inode_init_security hook
> and just do the EVM changes (see below for the motivation).
>
>>> From EVM side, the first operation to be done is to change the definition
>>> of evm_inode_init_security() to be compatible with the security hook
>>> definition. Unfortunately, the current definition does not provide enough
>>> information for EVM, as it must have visibility of all xattrs provided by
>>> LSMs to correctly calculate the HMAC. This patch set changes the security
>>> hook definition by adding the full array of xattr as a parameter.
>> Why do you want to call evm_inode_init_security() as a regular LSM hook?
>> Except for the names evm_inode_init_security() and
>> selinux_inode_init_security()
>> have nothing in common. They do very different things and require different
>> data, as comes out in the patches.
> I thought that it would be more clean if all hooks are registered
> to the LSM infrastructure. Otherwise, it could happen that some
> hooks are still executed even if the LSM is not active, from the
> perspective of the LSM infrastructure.
>
> evm_inode_init_security() is still a provider of xattrs, like the
> other LSMs, just it requires an extra parameter to calculate
> the HMAC.
>
>> There are evm functions that could be implemented as LSM hooks. I don't think
>> this is one of them. There's no point in going overboard.
> IMA and EVM both use a cache to store the integrity verification,
> which is currently not managed by the LSM infrastructure but
> by an ad-hoc mechanism implemented with an rbtree.
>
> One of the benefits of defining both IMA and EVM as an LSM
> is that we can switch from this ad-hoc mechanism to the one
> implemented for the LSM infrastructure, with a search in
> constant time. Given that evm_inode_init_security() would
> update the integrity status (xattrs are good at inode creation
> time), I would add it as well to the LSM infrastructure.
>
> One additional motivation for defining EVM as an LSM is that
> it would solve one of the EVM limitations that affects its
> usability: partial copy of xattrs (e.g. by cp and tar) would not
> work when an HMAC key is loaded because, since EVM in
> the post set/removexattr hook does not know the status
> of the last integrity verification, it has to deny the permission
> to perform the xattr operation, to avoid that the HMAC is
> calculated on corrupted xattrs. Having the status in the
> per-inode blob would solve this issue more efficiently than
> adding a cache for each verified inode in the rbtree.
>
> Would you see this as an useful modification?
Yes, I think that would be worthwhile.
My biggest objection is to adding a parameter to the hook calls.
The security_inode_init_security() - security_old_inode_init_security()
organization looks wrong to me as written.
There are really three cases here:
Neither EVM nor initxattrs - taken care of by the "old" variant.
EVM, but no initxattrs - which doesn't gather the EVM data.
EVM and initxattrs - which gathers and uses the EVM data.
The code we have now is cleanest for the least common "old" variant,
which is used in only two places, reiserfs and ocfs2. I would suggest
a slightly different approach to getting you what you're after.
Let's change the hook definition for inode_init_security to take a
struct xattr * and the fs_data rather than the name/value/length triple.
It will require a temporary struct xattr in security_old_init_inode_security,
but that's a corner case anyway. The security module specific code would be
easy to adapt. In the current environment, where there can only be one
module providing a hook, SELinux or Smack will fill in the xattr and return.
In the future the modules will have to find an empty slot for their data.
If your evm_init_inode_security() is registered last you will get
the desired behavior.
The MAX_LSM_EVM_XATTR value can be easily computed at compile time:
#define MAX_LSM_EVM_XATTR ( 1 + \
( IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0 ) + \
( IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) )
Yes, you'll waste stack if only one of the modules is active.
On the other hand, if you only compile in one the value will be
perfect and you'll avoid allocation and associated headaches.
>
> Thanks
>
> Roberto
>
> HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
> Managing Director: Li Peng, Li Jian, Shi Yanli
>
>>> Secondly, EVM must know how many elements are in the xattr array. It
>> seems
>>> that it is not necessary to add another parameter, as all filesystems
that
>>> define an initxattr function, expect that the last element of the array
>> is
>>> one with the name field set to NULL. EVM reuses the same assumption.
>>>
>>> This patch set has been tested by introducing several instances of a
>>> TestLSM (some providing an xattr, some not, one with a wrong
>> implementation
>>> to see how the LSM infrastructure handles it). The patch is not included
>>> in this set but it is available here:
>>>
>>>
>> https://github.com/robertosassu/linux/commit/0370ff0fbc16e5d63489836a95
>> 8e65d697f956db
>>> The test, added to ima-evm-utils, is available here:
>>>
>>> https://github.com/robertosassu/ima-evm-utils/blob/evm-multiple-lsms-v1-
>> devel-v1/tests/evm_multiple_lsms.test
>>> The test takes a UML kernel built by Travis and launches it several times,
>>> each time with a different combination of LSMs. After boot, it first checks
>>> that there is an xattr for each LSM providing it, and then calculates
the
>>> HMAC in user space and compares it with the HMAC calculated by EVM in
>>> kernel space.
>>>
>>> A test report can be obtained here:
>>>
>>> https://www.travis-ci.com/github/robertosassu/ima-evm-
>> utils/jobs/498699540
>>> Lastly, running the test on reiserfs to check
>>> security_old_inode_init_security(), some issues have been discovered:
a
>>> free of xattr->name which is not correct after commit 9548906b2bb7 ('xattr:
>>> Constify ->name member of "struct xattr"'), and a misalignment with
>>> security_inode_init_security() (the old version expects the full xattr name
>>> with the security. prefix, the new version just the suffix). The last
issue
>>> has not been fixed yet.
>>>
>>> Roberto Sassu (5):
>>> xattr: Complete constify ->name member of "struct xattr"
>>> security: Support multiple LSMs implementing the inode_init_security
>>> hook
>>> security: Pass xattrs allocated by LSMs to the inode_init_security
>>> hook
>>> evm: Align evm_inode_init_security() definition with LSM
>>> infrastructure
>>> evm: Support multiple LSMs providing an xattr
>>>
>>> fs/reiserfs/xattr_security.c | 2 -
>>> include/linux/evm.h | 21 ++++---
>>> include/linux/lsm_hook_defs.h | 2 +-
>>> include/linux/lsm_hooks.h | 5 +-
>>> security/integrity/evm/evm.h | 2 +
>>> security/integrity/evm/evm_crypto.c | 9 ++-
>>> security/integrity/evm/evm_main.c | 35 +++++++----
>>> security/security.c | 95 +++++++++++++++++++++++------
>>> security/selinux/hooks.c | 3 +-
>>> security/smack/smack_lsm.c | 4 +-
>>> 10 files changed, 135 insertions(+), 43 deletions(-)
>>>
> From: Casey Schaufler [mailto:[email protected]]
> Sent: Friday, April 16, 2021 11:25 PM
> On 4/16/2021 9:37 AM, Roberto Sassu wrote:
> >> From: Casey Schaufler [mailto:[email protected]]
> >> Sent: Thursday, April 15, 2021 10:44 PM
> >> On 4/15/2021 3:04 AM, Roberto Sassu wrote:
> >>> This patch set depends on:
> >>>
> >>> https://lore.kernel.org/linux-integrity/20210409114313.4073-1-
> >> [email protected]/
> >>> https://lore.kernel.org/linux-integrity/20210407105252.30721-1-
> >> [email protected]/
> >>> One of the challenges that must be tackled to move IMA and EVM to the
> LSM
> >>> infrastructure is to ensure that EVM is capable to correctly handle
> >>> multiple stacked LSMs providing an xattr at file creation. At the moment,
> >>> there are few issues that would prevent a correct integration. This patch
> >>> set aims at solving them.
> >>>
> >>> From the LSM infrastructure side, the LSM stacking feature added the
> >>> possibility of registering multiple implementations of the security hooks,
> >>> that are called sequentially whenever someone calls the corresponding
> >>> security hook. However, security_inode_init_security() and
> >>> security_old_inode_init_security() are currently limited to support one
> >>> xattr provided by LSM and one by EVM.
> >> That is correct. At present the only two modules that provide extended
> >> attributes are SELinux and Smack. The LSM infrastructure requires more
> >> change, including change to security_inode_init_security(), before those
> >> modules can be used together.
> > One of the goals of this patch set is to solve the specific problem
> > of security_inode_init_security(), when arbitrary LSMs are added
> > to the LSM infrastructure. Given that some problems have
> > been already identified, and will arise when a new LSM
> > providing an implementation for the inode_init_security hook
> > will be added to the LSM infrastructure, it seems a good idea
> > fixing them. We could discuss about the solution, if there is
> > a better approach.
> >
> >>> In addition, using the call_int_hook() macro causes some issues. According
> >>> to the documentation in include/linux/lsm_hooks.h, it is a legitimate
> case
> >>> that an LSM returns -EOPNOTSUPP when it does not want to provide an
> xattr.
> >>> However, the loop defined in the macro would stop calling subsequent
> LSMs
> >>> if that happens. In the case of security_old_inode_init_security(), using
> >>> the macro would also cause a memory leak due to replacing the *value
> >>> pointer, if multiple LSMs provide an xattr.
> >> As there is no case where there will be multiple providers of hooks for
> >> inode_init_security this isn't an issue.
> > I could skip the patches that are not required to support
> > multiple LSMs registering to the inode_init_security hook
> > and just do the EVM changes (see below for the motivation).
> >
> >>> From EVM side, the first operation to be done is to change the definition
> >>> of evm_inode_init_security() to be compatible with the security hook
> >>> definition. Unfortunately, the current definition does not provide enough
> >>> information for EVM, as it must have visibility of all xattrs provided by
> >>> LSMs to correctly calculate the HMAC. This patch set changes the security
> >>> hook definition by adding the full array of xattr as a parameter.
> >> Why do you want to call evm_inode_init_security() as a regular LSM hook?
> >> Except for the names evm_inode_init_security() and
> >> selinux_inode_init_security()
> >> have nothing in common. They do very different things and require different
> >> data, as comes out in the patches.
> > I thought that it would be more clean if all hooks are registered
> > to the LSM infrastructure. Otherwise, it could happen that some
> > hooks are still executed even if the LSM is not active, from the
> > perspective of the LSM infrastructure.
> >
> > evm_inode_init_security() is still a provider of xattrs, like the
> > other LSMs, just it requires an extra parameter to calculate
> > the HMAC.
> >
> >> There are evm functions that could be implemented as LSM hooks. I don't
> think
> >> this is one of them. There's no point in going overboard.
> > IMA and EVM both use a cache to store the integrity verification,
> > which is currently not managed by the LSM infrastructure but
> > by an ad-hoc mechanism implemented with an rbtree.
> >
> > One of the benefits of defining both IMA and EVM as an LSM
> > is that we can switch from this ad-hoc mechanism to the one
> > implemented for the LSM infrastructure, with a search in
> > constant time. Given that evm_inode_init_security() would
> > update the integrity status (xattrs are good at inode creation
> > time), I would add it as well to the LSM infrastructure.
> >
> > One additional motivation for defining EVM as an LSM is that
> > it would solve one of the EVM limitations that affects its
> > usability: partial copy of xattrs (e.g. by cp and tar) would not
> > work when an HMAC key is loaded because, since EVM in
> > the post set/removexattr hook does not know the status
> > of the last integrity verification, it has to deny the permission
> > to perform the xattr operation, to avoid that the HMAC is
> > calculated on corrupted xattrs. Having the status in the
> > per-inode blob would solve this issue more efficiently than
> > adding a cache for each verified inode in the rbtree.
> >
> > Would you see this as an useful modification?
>
> Yes, I think that would be worthwhile.
>
> My biggest objection is to adding a parameter to the hook calls.
> The security_inode_init_security() - security_old_inode_init_security()
> organization looks wrong to me as written.
>
> There are really three cases here:
> Neither EVM nor initxattrs - taken care of by the "old" variant.
> EVM, but no initxattrs - which doesn't gather the EVM data.
> EVM and initxattrs - which gathers and uses the EVM data.
>
> The code we have now is cleanest for the least common "old" variant,
> which is used in only two places, reiserfs and ocfs2. I would suggest
> a slightly different approach to getting you what you're after.
>
> Let's change the hook definition for inode_init_security to take a
> struct xattr * and the fs_data rather than the name/value/length triple.
I added struct xattr **, which is updated by LSMs with the slot they found,
so that security_inode_init_security() checks the validity of the xattr (if an
LSM returned 0, both the name and value must be set). If this is not
necessary, I switch to struct xattr *.
> It will require a temporary struct xattr in security_old_init_inode_security,
> but that's a corner case anyway. The security module specific code would be
> easy to adapt. In the current environment, where there can only be one
> module providing a hook, SELinux or Smack will fill in the xattr and return.
> In the future the modules will have to find an empty slot for their data.
I was thinking to add the code a new LSM should include both in SELinux
and Smack, given that probably people use them as a reference.
> If your evm_init_inode_security() is registered last you will get
> the desired behavior.
>
> The MAX_LSM_EVM_XATTR value can be easily computed at compile time:
>
> #define MAX_LSM_EVM_XATTR ( 1 + \
> ( IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0 ) + \
> ( IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) )
> Yes, you'll waste stack if only one of the modules is active.
> On the other hand, if you only compile in one the value will be
> perfect and you'll avoid allocation and associated headaches.
Given that there is allocation for the value anyway, would it be
a big problem to allocate the xattr array too? The advantage
would be to make the code ready for development of new LSMs.
Thanks
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli
> > Thanks
> >
> > Roberto
> >
> > HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
> > Managing Director: Li Peng, Li Jian, Shi Yanli
> >
> >>> Secondly, EVM must know how many elements are in the xattr array. It
> >> seems
> >>> that it is not necessary to add another parameter, as all filesystems
> that
> >>> define an initxattr function, expect that the last element of the array
> >> is
> >>> one with the name field set to NULL. EVM reuses the same assumption.
> >>>
> >>> This patch set has been tested by introducing several instances of a
> >>> TestLSM (some providing an xattr, some not, one with a wrong
> >> implementation
> >>> to see how the LSM infrastructure handles it). The patch is not included
> >>> in this set but it is available here:
> >>>
> >>>
> >>
> https://github.com/robertosassu/linux/commit/0370ff0fbc16e5d63489836a95
> >> 8e65d697f956db
> >>> The test, added to ima-evm-utils, is available here:
> >>>
> >>> https://github.com/robertosassu/ima-evm-utils/blob/evm-multiple-lsms-
> v1-
> >> devel-v1/tests/evm_multiple_lsms.test
> >>> The test takes a UML kernel built by Travis and launches it several times,
> >>> each time with a different combination of LSMs. After boot, it first checks
> >>> that there is an xattr for each LSM providing it, and then calculates
> the
> >>> HMAC in user space and compares it with the HMAC calculated by EVM in
> >>> kernel space.
> >>>
> >>> A test report can be obtained here:
> >>>
> >>> https://www.travis-ci.com/github/robertosassu/ima-evm-
> >> utils/jobs/498699540
> >>> Lastly, running the test on reiserfs to check
> >>> security_old_inode_init_security(), some issues have been discovered:
> a
> >>> free of xattr->name which is not correct after commit 9548906b2bb7
> ('xattr:
> >>> Constify ->name member of "struct xattr"'), and a misalignment with
> >>> security_inode_init_security() (the old version expects the full xattr name
> >>> with the security. prefix, the new version just the suffix). The last
> issue
> >>> has not been fixed yet.
> >>>
> >>> Roberto Sassu (5):
> >>> xattr: Complete constify ->name member of "struct xattr"
> >>> security: Support multiple LSMs implementing the inode_init_security
> >>> hook
> >>> security: Pass xattrs allocated by LSMs to the inode_init_security
> >>> hook
> >>> evm: Align evm_inode_init_security() definition with LSM
> >>> infrastructure
> >>> evm: Support multiple LSMs providing an xattr
> >>>
> >>> fs/reiserfs/xattr_security.c | 2 -
> >>> include/linux/evm.h | 21 ++++---
> >>> include/linux/lsm_hook_defs.h | 2 +-
> >>> include/linux/lsm_hooks.h | 5 +-
> >>> security/integrity/evm/evm.h | 2 +
> >>> security/integrity/evm/evm_crypto.c | 9 ++-
> >>> security/integrity/evm/evm_main.c | 35 +++++++----
> >>> security/security.c | 95 +++++++++++++++++++++++------
> >>> security/selinux/hooks.c | 3 +-
> >>> security/smack/smack_lsm.c | 4 +-
> >>> 10 files changed, 135 insertions(+), 43 deletions(-)
> >>>