Critical data structures of security modules are currently not measured.
Therefore an attestation service, for instance, would not be able to
attest whether the security modules are always operating with the policies
and configuration that the system administrator had setup. The policies
and configuration for the security modules could be tampered with by
malware by exploiting Kernel vulnerabilities or modified through some
inadvertent actions on the system. Measuring such critical data would
enable an attestation service to better assess the state of the system.
IMA subsystem measures system files, command line arguments passed to
kexec, boot aggregate, keys, etc. It can be used to measure critical
data structures of security modules as well.
This change aims to address measuring critical data structures
of security modules when they are initialized, when they are updated
at runtime, and also periodically to detect any tampering.
This change set is based off of Linux Kernel version 5.8-rc5.
The following patch needs to be applied first before applying
the patches in this patch set:
https://patchwork.kernel.org/patch/11612989/
Change log:
v3:
=> Loop through policy_capabilities to build the state data
to measure instead of hardcoding to current set of
policy capabilities.
=> Added error log messages for failure conditions.
v2:
=> Pass selinux_state struct as parameter to the function
that measures SELinux data.
=> Use strings from selinux_policycap_names array for SELinux
state measurement.
=> Refactored security_read_policy() to alloc kernel or user
virtual memory and then read the SELinux policy.
v1:
=> Per Stephen Smalley's suggestion added selinux_state booleans
and hash of SELinux policy in the measured data for SELinux.
=> Call IMA hook from the security module directly instead of
redirecting through the LSM.
Lakshmi Ramasubramanian (5):
IMA: Add LSM_STATE func to measure LSM data
IMA: Define an IMA hook to measure LSM data
LSM: Add security_measure_data in lsm_info struct
LSM: Define SELinux function to measure security state
LSM: Define workqueue for measuring security module state
Documentation/ABI/testing/ima_policy | 6 +-
include/linux/ima.h | 4 +
include/linux/lsm_hooks.h | 3 +
security/integrity/ima/ima.h | 1 +
security/integrity/ima/ima_api.c | 2 +-
security/integrity/ima/ima_main.c | 17 +++
security/integrity/ima/ima_policy.c | 29 ++++-
security/security.c | 74 ++++++++++++-
security/selinux/Makefile | 2 +
security/selinux/hooks.c | 4 +
security/selinux/include/security.h | 18 ++++
security/selinux/measure.c | 155 +++++++++++++++++++++++++++
security/selinux/selinuxfs.c | 1 +
security/selinux/ss/services.c | 66 ++++++++++--
14 files changed, 365 insertions(+), 17 deletions(-)
create mode 100644 security/selinux/measure.c
--
2.27.0
IMA subsystem needs to define an IMA hook that the security modules can
call to measure critical data of the security modules.
Define a new IMA hook, namely ima_lsm_state(), that the security modules
can call to measure data.
Signed-off-by: Lakshmi Ramasubramanian <redacted>
---
include/linux/ima.h | 4 ++++
security/integrity/ima/ima_main.c | 17 +++++++++++++++++
2 files changed, 21 insertions(+)
Data structures critical to the functioning of a security module could
be tampered with by malware or changed inadvertently at runtime
thereby disabling or reducing the security guarantees provided by
the security module. Such critical data need to be periodically checked
and measured, if there is any change. This would enable an attestation
service, for instance, to verify that the security modules are operating
with the configuration and policy setup by the system administrator.
Define a workqueue in the LSM and invoke the security modules in
the workqueue handler to check their data and measure.
Note that the data given by the security module would be measured by
the IMA subsystem only if it has changed since the last time it was
measured.
Signed-off-by: Lakshmi Ramasubramanian <redacted>
---
security/security.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
The security modules that require their data to be measured using
the IMA subsystem need to define a function that the LSM can call
to trigger the measurement.
Add a function pointer field namely security_measure_data in lsm_info
structure. Update LSM to call this security module function, if defined,
to measure the security module's data using the IMA subsystem.
Signed-off-by: Lakshmi Ramasubramanian <redacted>
---
include/linux/lsm_hooks.h | 3 +++
security/security.c | 48 ++++++++++++++++++++++++++++++++++++++-
2 files changed, 50 insertions(+), 1 deletion(-)
SELinux configuration and policy are some of the critical data for this
security module that needs to be measured. To enable this measurement
SELinux needs to implement the interface function,
security_measure_data(), that the LSM can call.
Define the security_measure_data() function in SELinux to measure SELinux
configuration and policy. Call this function to measure SELinux data
when there is a change in the security module's state.
Sample measurement of SELinux state and hash of the policy:
10 e32e...5ac3 ima-buf sha256:86e8...4594 selinux-state 656e61626c65643d313b656e666f7263696e673d303b636865636b72657170726f743d313b6e6574706565723d313b6f70656e7065726d3d313b657874736f636b636c6173733d313b616c776179736e6574776f726b3d303b6367726f75707365636c6162656c3d313b6e6e706e6f737569647472616e736974696f6e3d313b67656e66737365636c6162656c73796d6c696e6b3d303b
10 f4a7...9408 ima-buf sha256:4941...68fc selinux-policy-hash 8d1d...1834
To verify the measurement check the following:
Execute the following command to extract the measured data
from the IMA log for SELinux configuration (selinux-state).
cat /sys/kernel/security/integrity/ima/ascii_runtime_measurements | grep -m 1 "selinux-state" | cut -d' ' -f 6 | xxd -r -p
The output should be the list of key-value pairs. For example,
enabled=1;enforcing=0;checkreqprot=1;network_peer_controls=1;open_perms=1;extended_socket_class=1;always_check_network=0;cgroup_seclabel=1;nnp_nosuid_transition=1;genfs_seclabel_symlinks=0;
To verify the measured data with the current SELinux state:
=> enabled should be set to 1 if /sys/fs/selinux folder exists,
0 otherwise
For other entries, compare the integer value in the files
=> /sys/fs/selinux/enforce
=> /sys/fs/selinux/checkreqprot
And, each of the policy capabilities files under
=> /sys/fs/selinux/policy_capabilities
The data for selinux-policy-hash is the SHA256 hash of SELinux policy.
To verify the measured data with the current SELinux policy run
the following commands and verify the output hash values match.
sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1
cat /sys/kernel/security/integrity/ima/ascii_runtime_measurements | grep -m 1 "selinux-policy-hash" | cut -d' ' -f 6
Signed-off-by: Lakshmi Ramasubramanian <redacted>
Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
---
security/selinux/Makefile | 2 +
security/selinux/hooks.c | 4 +
security/selinux/include/security.h | 18 ++++
security/selinux/measure.c | 155 ++++++++++++++++++++++++++++
security/selinux/selinuxfs.c | 1 +
security/selinux/ss/services.c | 66 ++++++++++--
6 files changed, 237 insertions(+), 9 deletions(-)
create mode 100644 security/selinux/measure.c
@@ -0,0 +1,155 @@+// SPDX-License-Identifier: GPL-2.0-or-later+/*+*MeasureSELinuxstateusingIMAsubsystem.+*/+#include<linux/ima.h>+#include"security.h"++/* Pre-allocated buffer used for measuring state */+staticchar*selinux_state_string;+staticsize_tselinux_state_string_len;+staticchar*str_format="%s=%d;";+staticintselinux_state_count;++void__initselinux_init_measurement(void)+{+inti;++/*+*enabled+*enforcing+*checkreqport+*Allpolicycapabilityflags+*/+selinux_state_count=3+__POLICYDB_CAPABILITY_MAX;++selinux_state_string_len=snprintf(NULL,0,str_format,+"enabled",0);+selinux_state_string_len+=snprintf(NULL,0,str_format,+"enforcing",0);+selinux_state_string_len+=snprintf(NULL,0,str_format,+"checkreqprot",0);+for(i=3;i<selinux_state_count;i++){+selinux_state_string_len+=+snprintf(NULL,0,str_format,+selinux_policycap_names[i-3],0);+}+++selinux_state_string_len;++selinux_state_string=kzalloc(selinux_state_string_len,GFP_KERNEL);+if(!selinux_state_string){+pr_warn("Failed to alloc memory for SELinux measurement\n");+selinux_state_string_len=0;+}+}++staticintselinux_hash_policy(constchar*hash_alg_name,+void*policy,size_tpolicy_len,+void**policy_hash,int*policy_hash_len)+{+structcrypto_shash*tfm;+structshash_desc*desc=NULL;+void*digest=NULL;+intdesc_size;+intdigest_size;+intret=0;++tfm=crypto_alloc_shash(hash_alg_name,0,0);+if(IS_ERR(tfm))+returnPTR_ERR(tfm);++desc_size=crypto_shash_descsize(tfm)+sizeof(*desc);+digest_size=crypto_shash_digestsize(tfm);++digest=kmalloc(digest_size,GFP_KERNEL);+if(!digest){+ret=-ENOMEM;+gotoerror;+}++desc=kzalloc(desc_size,GFP_KERNEL);+if(!desc){+ret=-ENOMEM;+gotoerror;+}++desc->tfm=tfm;++ret=crypto_shash_digest(desc,policy,policy_len,digest);+if(ret<0)+gotoerror;++*policy_hash_len=digest_size;+*policy_hash=digest;+digest=NULL;++error:+kfree(desc);+kfree(digest);++crypto_free_shash(tfm);++returnret;+}++voidselinux_measure_state(structselinux_state*selinux_state)+{+void*policy=NULL;+void*policy_hash=NULL;+size_tcurr,buflen;+inti,policy_hash_len,rc=0;++if(!selinux_initialized(selinux_state)){+pr_warn("%s: SELinux not yet initialized.\n",__func__);+return;+}++if(!selinux_state_string){+pr_warn("%s: Buffer for state not allocated.\n",__func__);+return;+}++curr=snprintf(selinux_state_string,selinux_state_string_len,+str_format,"enabled",+!selinux_disabled(selinux_state));+curr+=snprintf((selinux_state_string+curr),+(selinux_state_string_len-curr),+str_format,"enforcing",+enforcing_enabled(selinux_state));+curr+=snprintf((selinux_state_string+curr),+(selinux_state_string_len-curr),+str_format,"checkreqprot",+selinux_checkreqprot(selinux_state));++for(i=3;i<selinux_state_count;i++){+curr+=snprintf((selinux_state_string+curr),+(selinux_state_string_len-curr),+str_format,+selinux_policycap_names[i-3],+selinux_state->policycap[i-3]);+}++if(curr>=0&&curr<selinux_state_string_len)+ima_lsm_state("selinux-state",selinux_state_string,curr);+else{+rc=-EINVAL;+gotoout;+}++rc=security_read_policy_kernel(selinux_state,&policy,&buflen);+if(!rc)+rc=selinux_hash_policy("sha256",policy,buflen,+&policy_hash,&policy_hash_len);+if(!rc)+ima_lsm_state("selinux-policy-hash",policy_hash,+policy_hash_len);++out:+vfree(policy);+kfree(policy_hash);+}++voidselinux_measure_data(void)+{+selinux_measure_state(&selinux_state);+}
Critical data structures of security modules need to be measured to
enable an attestation service to verify if the policies and
configuration have been setup correctly and that they haven't been
tampered with at runtime. A new IMA policy is required for handling
this measurement.
Define a new IMA policy func namely LSM_STATE to measure data provided
by security modules. Update ima_match_rules() to check for LSM_STATE
and ima_parse_rule() to handle LSM_STATE.
Signed-off-by: Lakshmi Ramasubramanian <redacted>
---
Documentation/ABI/testing/ima_policy | 6 +++++-
security/integrity/ima/ima.h | 1 +
security/integrity/ima/ima_api.c | 2 +-
security/integrity/ima/ima_policy.c | 29 +++++++++++++++++++++++-----
4 files changed, 31 insertions(+), 7 deletions(-)
@@ -125,3 +125,7 @@ Description: keys added to .builtin_trusted_keys or .ima keyring: measure func=KEY_CHECK keyrings=.builtin_trusted_keys|.ima++ Example of measure rule using LSM_STATE to measure LSM data:++ measure func=LSM_STATE
From: kernel test robot <hidden> Date: 2020-07-18 03:16:17
Hi Lakshmi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on integrity/next-integrity]
[cannot apply to pcmoore-selinux/next security/next-testing linus/master v5.8-rc5 next-20200717]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Lakshmi-Ramasubramanian/LSM-Measure-security-module-state/20200718-063111
base: https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git next-integrity
config: parisc-allyesconfig (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=parisc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <redacted>
All errors (new ones prefixed by >>):
security/selinux/measure.c: In function 'selinux_measure_state':
security/selinux/measure.c:132:11: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
132 | if (curr >= 0 && curr < selinux_state_string_len)
| ^~
quoted
security/selinux/measure.c:148:2: error: implicit declaration of function 'vfree'; did you mean 'kvfree'? [-Werror=implicit-function-declaration]
security/selinux/measure.c:57:6: warning: assignment to 'struct crypto_shash *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
From: kernel test robot <hidden> Date: 2020-07-18 15:34:22
Hi Lakshmi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on integrity/next-integrity]
[cannot apply to pcmoore-selinux/next security/next-testing linus/master v5.8-rc5 next-20200717]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Lakshmi-Ramasubramanian/LSM-Measure-security-module-state/20200718-063111
base: https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git next-integrity
config: x86_64-randconfig-s022-20200717 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-49-g707c5017-dirty
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <redacted>
sparse warnings: (new ones prefixed by >>)
quoted
security/selinux/ss/services.c:3737:5: sparse: sparse: symbol 'security_read_selinux_policy' was not declared. Should it be static?
Hi Lakshmi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on integrity/next-integrity]
[cannot apply to pcmoore-selinux/next security/next-testing linus/master v5.8-rc5 next-20200717]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
Thank you for catching this.
I did not see these failures with the compiler and make options I'd used.
Am able to reproduce the errors with the instructions you'd provided.
Will post the updated patches shortly.
thanks,
-lakshmi
From: Stephen Smalley <stephen.smalley.work@gmail.com> Date: 2020-07-20 14:31:48
On Fri, Jul 17, 2020 at 6:28 PM Lakshmi Ramasubramanian
[off-list ref] wrote:
SELinux configuration and policy are some of the critical data for this
security module that needs to be measured. To enable this measurement
SELinux needs to implement the interface function,
security_measure_data(), that the LSM can call.
Define the security_measure_data() function in SELinux to measure SELinux
configuration and policy. Call this function to measure SELinux data
when there is a change in the security module's state.
Sample measurement of SELinux state and hash of the policy:
10 e32e...5ac3 ima-buf sha256:86e8...4594 selinux-state 656e61626c65643d313b656e666f7263696e673d303b636865636b72657170726f743d313b6e6574706565723d313b6f70656e7065726d3d313b657874736f636b636c6173733d313b616c776179736e6574776f726b3d303b6367726f75707365636c6162656c3d313b6e6e706e6f737569647472616e736974696f6e3d313b67656e66737365636c6162656c73796d6c696e6b3d303b
10 f4a7...9408 ima-buf sha256:4941...68fc selinux-policy-hash 8d1d...1834
To verify the measurement check the following:
Execute the following command to extract the measured data
from the IMA log for SELinux configuration (selinux-state).
cat /sys/kernel/security/integrity/ima/ascii_runtime_measurements | grep -m 1 "selinux-state" | cut -d' ' -f 6 | xxd -r -p
The output should be the list of key-value pairs. For example,
enabled=1;enforcing=0;checkreqprot=1;network_peer_controls=1;open_perms=1;extended_socket_class=1;always_check_network=0;cgroup_seclabel=1;nnp_nosuid_transition=1;genfs_seclabel_symlinks=0;
To verify the measured data with the current SELinux state:
=> enabled should be set to 1 if /sys/fs/selinux folder exists,
0 otherwise
For other entries, compare the integer value in the files
=> /sys/fs/selinux/enforce
=> /sys/fs/selinux/checkreqprot
And, each of the policy capabilities files under
=> /sys/fs/selinux/policy_capabilities
The data for selinux-policy-hash is the SHA256 hash of SELinux policy.
To verify the measured data with the current SELinux policy run
the following commands and verify the output hash values match.
sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1
cat /sys/kernel/security/integrity/ima/ascii_runtime_measurements | grep -m 1 "selinux-policy-hash" | cut -d' ' -f 6
Signed-off-by: Lakshmi Ramasubramanian <redacted>
Suggested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
---
@@ -0,0 +1,155 @@+// SPDX-License-Identifier: GPL-2.0-or-later+/*+*MeasureSELinuxstateusingIMAsubsystem.+*/+#include<linux/ima.h>+#include"security.h"++/* Pre-allocated buffer used for measuring state */+staticchar*selinux_state_string;+staticsize_tselinux_state_string_len;+staticchar*str_format="%s=%d;";+staticintselinux_state_count;++void__initselinux_init_measurement(void)+{+inti;++/*+*enabled+*enforcing+*checkreqport
checkreqprot (spelling)
What about initialized? Or do you consider that to be implicitly
true/1 else we wouldn't be taking a measurement? Only caveat there is
that it provides one more means of disabling measurements (at the same
time as disabling enforcement) by setting it to false/0 via kernel
write flaw.
We could measure the global state variables before full SELinux
initialization (i.e. policy load).
Only the policy hash depends on having loaded the policy.
Same question here as for the previous loop; seems cleaner to go from
0 to __POLICYDB_CAPABILITY_MAX and use [i].
What public git tree / branch would you recommend trying to use your
patches against? Didn't seem to apply to any of the obvious ones.
What about initialized? Or do you consider that to be implicitly
true/1 else we wouldn't be taking a measurement? Only caveat there is
that it provides one more means of disabling measurements (at the same
time as disabling enforcement) by setting it to false/0 via kernel
write flaw.
Yes - I was thinking measuring SELinux state would be meaningful only
when initialized is set to true/1.
I can include "initialized" as well in the measurement.
We could measure the global state variables before full SELinux
initialization (i.e. policy load).
Only the policy hash depends on having loaded the policy.
Thanks for the information. I'll measure the state variables always and
measure policy only if "initialized" is true/1.
Same question here as for the previous loop; seems cleaner to go from
0 to __POLICYDB_CAPABILITY_MAX and use [i].
Will change it.
What public git tree / branch would you recommend trying to use your
patches against? Didn't seem to apply to any of the obvious ones.
Please try it on Mimi's next-integrity branch
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git/log/?h=next-integrity
You can try it on Linus's mainline as well if you apply the following
patch first (have mentioned that in the Cover letter as well)
https://patchwork.kernel.org/patch/11612989/
Thanks for trying out the changes. Please let me know the defects you find.
Just to let you know - I am making the following change (will update in
the next patch):
=> Save the last policy hash and state string in selinux_state struct.
=> Measure policy and hash only if it has changed since the last
measurement.
=> Also, suffix the IMA event name used with time stamp. For example,
10 e32e...5ac3 ima-buf sha256:86e8...4594
selinux-state-1595257807:874963248
656e61626c65643d313b656e666f7263696e673d303b636865636b72657170726f743d313b6e6574706565723d313b6f70656e7065726d3d313b657874736f636b636c6173733d313b616c776179736e6574776f726b3d303b6367726f75707365636c6162656c3d313b6e6e706e6f737569647472616e736974696f6e3d313b67656e66737365636c6162656c73796d6c696e6b3d303b
10 f4a7...9408 ima-buf sha256:4941...68fc
selinux-policy-hash-1595257807:874963248
8d1d...1834
The above will ensure the following sequence will be measured:
#1 State A - Measured
#2 Change from State A to State B - Measured
#3 Change from State B back to State A - Since the measured data is
same as in #1, the change will be measured only if the event name is
different between #1 and #3
thanks,
-lakshmi
From: Stephen Smalley <stephen.smalley.work@gmail.com> Date: 2020-07-20 17:06:35
On Mon, Jul 20, 2020 at 11:17 AM Lakshmi Ramasubramanian
[off-list ref] wrote:
Thanks for trying out the changes. Please let me know the defects you find.
Just to let you know - I am making the following change (will update in
the next patch):
=> Save the last policy hash and state string in selinux_state struct.
=> Measure policy and hash only if it has changed since the last
measurement.
=> Also, suffix the IMA event name used with time stamp. For example,
10 e32e...5ac3 ima-buf sha256:86e8...4594
selinux-state-1595257807:874963248
656e61626c65643d313b656e666f7263696e673d303b636865636b72657170726f743d313b6e6574706565723d313b6f70656e7065726d3d313b657874736f636b636c6173733d313b616c776179736e6574776f726b3d303b6367726f75707365636c6162656c3d313b6e6e706e6f737569647472616e736974696f6e3d313b67656e66737365636c6162656c73796d6c696e6b3d303b
10 f4a7...9408 ima-buf sha256:4941...68fc
selinux-policy-hash-1595257807:874963248
8d1d...1834
The above will ensure the following sequence will be measured:
#1 State A - Measured
#2 Change from State A to State B - Measured
#3 Change from State B back to State A - Since the measured data is
same as in #1, the change will be measured only if the event name is
different between #1 and #3
Perhaps the timestamp / sequence number should be part of the hashed
data instead of the event name?
I can see the appraiser wanting to know two things:
1) The current state of the system (e.g. is it enforcing, is the
currently loaded policy the expected one?).
2) Has the system ever been in an unexpected state (e.g. was it
temporarily switched to permissive or had an unexpected policy
loaded?)
I applied the patch series on top of the next-integrity branch, added
measure func=LSM_STATE to ima-policy, and booted that kernel. I get
the following entries in ascii_runtime_measurements, but seemingly
missing the final field:
10 8a09c48af4f8a817f59b495bd82971e096e2e367 ima-ng
sha256:21c3d7b09b62b4d0b3ed15ba990f816b94808f90b76787bfae755c4b3a44cd24
selinux-state
10 e610908931d70990a2855ddb33c16af2d82ce56a ima-ng
sha256:c8898652afd5527ef4eaf8d85f5fee1d91fcccee34bc97f6e55b96746bedb318
selinux-policy-hash
Thus, I cannot verify. What am I missing?
On Mon, 2020-07-20 at 13:06 -0400, Stephen Smalley wrote:
I applied the patch series on top of the next-integrity branch, added
measure func=LSM_STATE to ima-policy, and booted that kernel. I get
the following entries in ascii_runtime_measurements, but seemingly
missing the final field:
10 8a09c48af4f8a817f59b495bd82971e096e2e367 ima-ng
sha256:21c3d7b09b62b4d0b3ed15ba990f816b94808f90b76787bfae755c4b3a44cd24
selinux-state
10 e610908931d70990a2855ddb33c16af2d82ce56a ima-ng
sha256:c8898652afd5527ef4eaf8d85f5fee1d91fcccee34bc97f6e55b96746bedb318
selinux-policy-hash
Thus, I cannot verify. What am I missing?
Missing is "template=ima-buf" on the policy rule.
Tyler's patch set just added some support for verifying the policy.
Refer to ima_validate_rule(). There are still some things missing.
For example, nayna noticed that making sure that asymmetric key
support is enabled. Another example is requiring "template=" for any
of the buffer measurements. Template names can be defined
dynamically, so it will need to support either format:
measure func=KEXEC_CMDLINE template=ima-buf
measure func=KEXEC_CMDLINE template=d-ng|n-ng|buf
Mimi
The above will ensure the following sequence will be measured:
#1 State A - Measured
#2 Change from State A to State B - Measured
#3 Change from State B back to State A - Since the measured data is
same as in #1, the change will be measured only if the event name is
different between #1 and #3
Perhaps the timestamp / sequence number should be part of the hashed
data instead of the event name?
If the timestamp/seqno is part of the hashed data, on every call to
measure IMA will add a new entry in the IMA log. This would fill up the
IMA log - even when there is no change in the measured data.
To avoid that I keep the last measurement in SELinux and measure only
when there is a change with the timestamp in the event name.
I can see the appraiser wanting to know two things:
1) The current state of the system (e.g. is it enforcing, is the
currently loaded policy the expected one?).
2) Has the system ever been in an unexpected state (e.g. was it
temporarily switched to permissive or had an unexpected policy
loaded?)
Yes - you are right.
The appraiser will have to look at the entire IMA log (and the
corresponding TPM PCR data) to know the above.
Time t0 => State of the system measured
Time tn => State changed and the new state measured
Time tm => State changed again and the new state measured.
Say, the measurement at "Time tn" was an illegal change, the appraiser
would know.
I applied the patch series on top of the next-integrity branch, added
measure func=LSM_STATE to ima-policy, and booted that kernel. I get
the following entries in ascii_runtime_measurements, but seemingly
missing the final field:
10 8a09c48af4f8a817f59b495bd82971e096e2e367 ima-ng
sha256:21c3d7b09b62b4d0b3ed15ba990f816b94808f90b76787bfae755c4b3a44cd24
selinux-state
10 e610908931d70990a2855ddb33c16af2d82ce56a ima-ng
sha256:c8898652afd5527ef4eaf8d85f5fee1d91fcccee34bc97f6e55b96746bedb318
selinux-policy-hash
Thus, I cannot verify. What am I missing?
Looks like the template used is ima-ng which doesn't include the
measured buffer. Please set template to "ima-buf" in the policy.
For example,
measure func=LSM_STATE template=ima-buf
thanks,
-lakshmi
From: Stephen Smalley <stephen.smalley.work@gmail.com> Date: 2020-07-20 17:41:08
On Mon, Jul 20, 2020 at 1:34 PM Lakshmi Ramasubramanian
[off-list ref] wrote:
On 7/20/20 10:06 AM, Stephen Smalley wrote:
quoted
quoted
The above will ensure the following sequence will be measured:
#1 State A - Measured
#2 Change from State A to State B - Measured
#3 Change from State B back to State A - Since the measured data is
same as in #1, the change will be measured only if the event name is
different between #1 and #3
Perhaps the timestamp / sequence number should be part of the hashed
data instead of the event name?
If the timestamp/seqno is part of the hashed data, on every call to
measure IMA will add a new entry in the IMA log. This would fill up the
IMA log - even when there is no change in the measured data.
To avoid that I keep the last measurement in SELinux and measure only
when there is a change with the timestamp in the event name.
quoted
I can see the appraiser wanting to know two things:
1) The current state of the system (e.g. is it enforcing, is the
currently loaded policy the expected one?).
2) Has the system ever been in an unexpected state (e.g. was it
temporarily switched to permissive or had an unexpected policy
loaded?)
Yes - you are right.
The appraiser will have to look at the entire IMA log (and the
corresponding TPM PCR data) to know the above.
Time t0 => State of the system measured
Time tn => State changed and the new state measured
Time tm => State changed again and the new state measured.
Say, the measurement at "Time tn" was an illegal change, the appraiser
would know.
quoted
I applied the patch series on top of the next-integrity branch, added
measure func=LSM_STATE to ima-policy, and booted that kernel. I get
the following entries in ascii_runtime_measurements, but seemingly
missing the final field:
10 8a09c48af4f8a817f59b495bd82971e096e2e367 ima-ng
sha256:21c3d7b09b62b4d0b3ed15ba990f816b94808f90b76787bfae755c4b3a44cd24
selinux-state
10 e610908931d70990a2855ddb33c16af2d82ce56a ima-ng
sha256:c8898652afd5527ef4eaf8d85f5fee1d91fcccee34bc97f6e55b96746bedb318
selinux-policy-hash
Thus, I cannot verify. What am I missing?
Looks like the template used is ima-ng which doesn't include the
measured buffer. Please set template to "ima-buf" in the policy.
For example,
measure func=LSM_STATE template=ima-buf
It seems like one shouldn't need to manually specify it if it is the
only template that yields a useful result for the LSM_STATE function?
From: Stephen Smalley <stephen.smalley.work@gmail.com> Date: 2020-07-20 17:49:57
On Mon, Jul 20, 2020 at 1:40 PM Stephen Smalley
[off-list ref] wrote:
On Mon, Jul 20, 2020 at 1:34 PM Lakshmi Ramasubramanian
[off-list ref] wrote:
quoted
On 7/20/20 10:06 AM, Stephen Smalley wrote:
quoted
quoted
The above will ensure the following sequence will be measured:
#1 State A - Measured
#2 Change from State A to State B - Measured
#3 Change from State B back to State A - Since the measured data is
same as in #1, the change will be measured only if the event name is
different between #1 and #3
Perhaps the timestamp / sequence number should be part of the hashed
data instead of the event name?
If the timestamp/seqno is part of the hashed data, on every call to
measure IMA will add a new entry in the IMA log. This would fill up the
IMA log - even when there is no change in the measured data.
To avoid that I keep the last measurement in SELinux and measure only
when there is a change with the timestamp in the event name.
quoted
I can see the appraiser wanting to know two things:
1) The current state of the system (e.g. is it enforcing, is the
currently loaded policy the expected one?).
2) Has the system ever been in an unexpected state (e.g. was it
temporarily switched to permissive or had an unexpected policy
loaded?)
Yes - you are right.
The appraiser will have to look at the entire IMA log (and the
corresponding TPM PCR data) to know the above.
Time t0 => State of the system measured
Time tn => State changed and the new state measured
Time tm => State changed again and the new state measured.
Say, the measurement at "Time tn" was an illegal change, the appraiser
would know.
quoted
I applied the patch series on top of the next-integrity branch, added
measure func=LSM_STATE to ima-policy, and booted that kernel. I get
the following entries in ascii_runtime_measurements, but seemingly
missing the final field:
10 8a09c48af4f8a817f59b495bd82971e096e2e367 ima-ng
sha256:21c3d7b09b62b4d0b3ed15ba990f816b94808f90b76787bfae755c4b3a44cd24
selinux-state
10 e610908931d70990a2855ddb33c16af2d82ce56a ima-ng
sha256:c8898652afd5527ef4eaf8d85f5fee1d91fcccee34bc97f6e55b96746bedb318
selinux-policy-hash
Thus, I cannot verify. What am I missing?
Looks like the template used is ima-ng which doesn't include the
measured buffer. Please set template to "ima-buf" in the policy.
For example,
measure func=LSM_STATE template=ima-buf
It seems like one shouldn't need to manually specify it if it is the
only template that yields a useful result for the LSM_STATE function?
Actually, if we used ima-ng template for selinux-policy-hash, then
instead of needing to hash the policy
first and passing the hash to IMA, we could just pass the policy as
the buffer and IMA would take care of the hashing, right?
And we only need to use ima-buf for the selinux-state if we want the
measurement list to include the string value that
was hashed; if we just want to compare against a known-good, it would
suffice to use ima-ng for it as well, right?
Looks like the template used is ima-ng which doesn't include the
measured buffer. Please set template to "ima-buf" in the policy.
For example,
measure func=LSM_STATE template=ima-buf
It seems like one shouldn't need to manually specify it if it is the
only template that yields a useful result for the LSM_STATE function?
Actually, if we used ima-ng template for selinux-policy-hash, then
instead of needing to hash the policy
first and passing the hash to IMA, we could just pass the policy as
the buffer and IMA would take care of the hashing, right?
That is correct.
The IMA hook I've added to measure LSM structures is a generic one that
can be used by any security module (SM). I feel it would be better to
not have policy or state or any such SM specific logic in IMA, but leave
that to the individual SM to handle.
What do you think?
And we only need to use ima-buf for the selinux-state if we want the
measurement list to include the string value that
was hashed; if we just want to compare against a known-good, it would
suffice to use ima-ng for it as well, right?
From: Stephen Smalley <stephen.smalley.work@gmail.com> Date: 2020-07-20 18:44:21
On Mon, Jul 20, 2020 at 2:27 PM Lakshmi Ramasubramanian
[off-list ref] wrote:
On 7/20/20 10:49 AM, Stephen Smalley wrote:
quoted
quoted
quoted
Looks like the template used is ima-ng which doesn't include the
measured buffer. Please set template to "ima-buf" in the policy.
For example,
measure func=LSM_STATE template=ima-buf
It seems like one shouldn't need to manually specify it if it is the
only template that yields a useful result for the LSM_STATE function?
Actually, if we used ima-ng template for selinux-policy-hash, then
instead of needing to hash the policy
first and passing the hash to IMA, we could just pass the policy as
the buffer and IMA would take care of the hashing, right?
That is correct.
The IMA hook I've added to measure LSM structures is a generic one that
can be used by any security module (SM). I feel it would be better to
not have policy or state or any such SM specific logic in IMA, but leave
that to the individual SM to handle.
What do you think?
It is correct to remain security module agnostic. However, I think
you can remain LSM-neutral while still avoiding the double hashing of
the policy here. Can't you just pass in the policy itself as the
buffer and let IMA hash it? Then you can let the policy author decide
on the template to be used (ima-buf versus ima-ng). If you want to
support the use of different templates for different "kinds" of LSM
state (e.g. state versus policy) you could either provide two funcs
(LSM_STATE, LSM_POLICY) or otherwise support selection based on some
other attribute.
Actually, if we used ima-ng template for selinux-policy-hash, then
instead of needing to hash the policy
first and passing the hash to IMA, we could just pass the policy as
the buffer and IMA would take care of the hashing, right?
That is correct.
The IMA hook I've added to measure LSM structures is a generic one that
can be used by any security module (SM). I feel it would be better to
not have policy or state or any such SM specific logic in IMA, but leave
that to the individual SM to handle.
What do you think?
It is correct to remain security module agnostic. However, I think
you can remain LSM-neutral while still avoiding the double hashing of
the policy here. Can't you just pass in the policy itself as the
buffer and let IMA hash it?
Yes - that is an option. If I do that then, as you have stated below,
we'll need to two funcs -
one that will only add the hash but not the entire data payload in the
IMA log (i.e., "ima-ng")
and, the other that handles hashing and including date payload (i.e.,
"ima-buf").
Then you can let the policy author decide
on the template to be used (ima-buf versus ima-ng). If you want to
support the use of different templates for different "kinds" of LSM
state (e.g. state versus policy) you could either provide two funcs
(LSM_STATE, LSM_POLICY) or otherwise support selection based on some
other attribute.