This patch set depends on:
https://lore.kernel.org/linux-integrity/20210409114313.4073-1-roberto.sassu@huawei.com/https://lore.kernel.org/linux-integrity/20210407105252.30721-1-roberto.sassu@huawei.com/
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 completes commit 9548906b2bb7 ('xattr: Constify ->name member of
"struct xattr"'). It fixes the documentation of the inode_init_security
hook, by removing the xattr name from the objects that are expected to be
allocated by LSMs (only the value is allocated). Also, it removes the
kfree() of name and setting it to NULL in the reiserfs code.
Fixes: 9548906b2bb7 ('xattr: Constify ->name member of "struct xattr"')
Cc: stable@vger.kernel.org
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
---
fs/reiserfs/xattr_security.c | 2 --
include/linux/lsm_hooks.h | 4 ++--
2 files changed, 2 insertions(+), 4 deletions(-)
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 <roberto.sassu@huawei.com>
---
security/security.c | 87 +++++++++++++++++++++++++++++++++++++--------
1 file changed, 72 insertions(+), 15 deletions(-)
@@ -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)
@@ -1038,23 +1037,56 @@ int security_inode_init_security(struct inode *inode, struct inode *dir,if(!initxattrs)returncall_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)+return0;++/* 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)+gotoout;++/* 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;+gotoout;+}++if(!ret&&lsm_xattr<new_xattrs+max_new_xattrs)+lsm_xattr++;+}++if(lsm_xattr==new_xattrs){+ret=-EOPNOTSUPP;gotoout;+}-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)gotoout;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,conststructqstr*qstr,constchar**name,void**value,size_t*len){+structsecurity_hook_list*P;+intret;+if(unlikely(IS_PRIVATE(inode)))return-EOPNOTSUPP;-returncall_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)+returnret;++/* 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)+returnret;+}++return-EOPNOTSUPP;}EXPORT_SYMBOL(security_old_inode_init_security);
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 <roberto.sassu@huawei.com>
---
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(-)
@@ -1036,7 +1036,7 @@ int security_inode_init_security(struct inode *inode, struct inode *dir,if(!initxattrs)returncall_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)
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 <roberto.sassu@huawei.com>
---
include/linux/evm.h | 21 ++++++++++++++-------
security/integrity/evm/evm_main.c | 24 +++++++++++++++---------
security/security.c | 7 +++++--
3 files changed, 34 insertions(+), 18 deletions(-)
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 <roberto.sassu@huawei.com>
---
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(-)
This patch completes commit 9548906b2bb7 ('xattr: Constify ->name member of
"struct xattr"'). It fixes the documentation of the inode_init_security
hook, by removing the xattr name from the objects that are expected to be
allocated by LSMs (only the value is allocated). Also, it removes the
kfree() of name and setting it to NULL in the reiserfs code.
Good catch, but well, grep does not find any reiserfs_security_free() callers.
Is reiserfs_security_free() a dead code?
This patch set depends on:
https://lore.kernel.org/linux-integrity/20210409114313.4073-1-roberto.sassu@huawei.com/https://lore.kernel.org/linux-integrity/20210407105252.30721-1-roberto.sassu@huawei.com/
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(-)
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.
quoted
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).
quoted
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
quoted
Secondly, EVM must know how many elements are in the xattr array. It
seems
quoted
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
quoted
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
quoted
to see how the LSM infrastructure handles it). The patch is not included
in this set but it is available here:
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
quoted
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(-)
One of the challenges that must be tackled to move IMA and EVM to the
LSM
quoted
quoted
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.
quoted
quoted
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
quoted
quoted
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).
quoted
quoted
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.
quoted
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
quoted
quoted
Secondly, EVM must know how many elements are in the xattr array. It
seems
quoted
that it is not necessary to add another parameter, as all filesystems
that
quoted
quoted
define an initxattr function, expect that the last element of the array
is
quoted
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
quoted
to see how the LSM infrastructure handles it). The patch is not included
in this set but it is available here:
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
Lastly, running the test on reiserfs to check
security_old_inode_init_security(), some issues have been discovered:
a
quoted
quoted
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
quoted
quoted
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(-)
One of the challenges that must be tackled to move IMA and EVM to the
LSM
quoted
quoted
quoted
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.
quoted
quoted
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
quoted
quoted
quoted
that an LSM returns -EOPNOTSUPP when it does not want to provide an
xattr.
quoted
quoted
quoted
However, the loop defined in the macro would stop calling subsequent
LSMs
quoted
quoted
quoted
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).
quoted
quoted
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.
quoted
There are evm functions that could be implemented as LSM hooks. I don't
think
quoted
quoted
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
quoted
Thanks
Roberto
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli
quoted
quoted
Secondly, EVM must know how many elements are in the xattr array. It
seems
quoted
that it is not necessary to add another parameter, as all filesystems
that
quoted
quoted
quoted
define an initxattr function, expect that the last element of the array
is
quoted
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
quoted
to see how the LSM infrastructure handles it). The patch is not included
in this set but it is available here:
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
Lastly, running the test on reiserfs to check
security_old_inode_init_security(), some issues have been discovered:
a
quoted
quoted
quoted
free of xattr->name which is not correct after commit 9548906b2bb7
('xattr:
quoted
quoted
quoted
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
quoted
quoted
quoted
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(-)