Re: [PATCH 2/2] SELinux: Measure state and hash of policy using IMA
On 8/17/20 4:11 PM, Mimi Zohar wrote: On Mon, 2020-08-17 at 15:33 -0700, Lakshmi Ramasubramanian wrote: On 8/17/20 3:00 PM, Casey Schaufler wrote: On 8/17/2020 2:31 PM, Mimi Zohar wrote: On Thu, 2020-08-13 at 14:13 -0400, Stephen Smalley wrote: On Thu, Aug 13, 2020 at 2:03 PM Lakshmi Ramasubramanian wrote: On 8/13/20 10:58 AM, Stephen Smalley wrote: On Thu, Aug 13, 2020 at 1:52 PM Lakshmi Ramasubramanian wrote: On 8/13/20 10:42 AM, Stephen Smalley wrote: diff --git a/security/selinux/measure.c b/security/selinux/measure.c new file mode 100644 index ..f21b7de4e2ae --- /dev/null +++ b/security/selinux/measure.c @@ -0,0 +1,204 @@ +static int selinux_hash_buffer(void *buf, size_t buf_len, + void **buf_hash, int *buf_hash_len) +{ +struct crypto_shash *tfm; +struct shash_desc *desc = NULL; +void *digest = NULL; +int desc_size; +int digest_size; +int ret = 0; + +tfm = crypto_alloc_shash("sha256", 0, 0); +if (IS_ERR(tfm)) +return PTR_ERR(tfm); Can we make the algorithm selectable via kernel parameter and/or writing to a new selinuxfs node? I can add a kernel parameter to select this hash algorithm. Also can we provide a Kconfig option for the default value like IMA does? Would we need both - Kconfig and kernel param? The other option is to provide an IMA function to return the current hash algorithm used for measurement. That way a consistent hash algorithm can be employed by both IMA and the callers. Would that be better? This is why I preferred just passing the serialized policy buffer to IMA and letting it handle the hashing. But apparently that approach wouldn't fly. IMA appears to support both a Kconfig option for selecting a default algorithm and a kernel parameter for overriding it. I assume the idea is that the distros can pick a reasonable default and then the end users can override that if they have specific requirements. I'd want the same for SELinux. If IMA is willing to export its hash algorithm to external components, then I'm willing to reuse that but not sure if that's a layering violation. With the new ima_measure_critical_data() hook, I agree with you and Casey it doesn't make sense for each caller to have to write their own function. Casey suggested exporting IMA's hash function or defining a new common hash function. There's nothing specific to IMA. Except that no one is going to use the function unless they're doing an IMA operation. Can we do the following instead: In ima_measure_critical_data() IMA hook, we can add another param for the caller to indicate whether => The contents of "buf" needs to be measured OR => Hash of the contents of "buf" needs to be measured. This way IMA doesn't need to export any new function to meet the hashing requirement. I'm not sure overloading the parameters is a good idea, but extending ima_measure_critical_data() to calculate a simple buffer hash should be fine. Sorry I wasn't clear - I didn't mean to say overload existing parameters, but extending the IMA hook to calculate the hash of the buffer - like the following: int ima_measure_critical_data(const char *event_name, const char *event_data_source, const void *buf, int buf_len, bool measure_buf_hash); If measure_buf_hash is true, IMA will calculate the hash of contents of "buf" and measure the hash. Else, IMA will measure the contents of "buf". -lakshmi
Re: [PATCH 2/2] SELinux: Measure state and hash of policy using IMA
On Mon, 2020-08-17 at 15:33 -0700, Lakshmi Ramasubramanian wrote: > On 8/17/20 3:00 PM, Casey Schaufler wrote: > > On 8/17/2020 2:31 PM, Mimi Zohar wrote: > > > On Thu, 2020-08-13 at 14:13 -0400, Stephen Smalley wrote: > > > > On Thu, Aug 13, 2020 at 2:03 PM Lakshmi Ramasubramanian > > > > wrote: > > > > > On 8/13/20 10:58 AM, Stephen Smalley wrote: > > > > > > On Thu, Aug 13, 2020 at 1:52 PM Lakshmi Ramasubramanian > > > > > > wrote: > > > > > > > On 8/13/20 10:42 AM, Stephen Smalley wrote: > > > > > > > > > > > > > > > > diff --git a/security/selinux/measure.c > > > > > > > > > b/security/selinux/measure.c > > > > > > > > > new file mode 100644 > > > > > > > > > index ..f21b7de4e2ae > > > > > > > > > --- /dev/null > > > > > > > > > +++ b/security/selinux/measure.c > > > > > > > > > @@ -0,0 +1,204 @@ > > > > > > > > > +static int selinux_hash_buffer(void *buf, size_t buf_len, > > > > > > > > > + void **buf_hash, int *buf_hash_len) > > > > > > > > > +{ > > > > > > > > > +struct crypto_shash *tfm; > > > > > > > > > +struct shash_desc *desc = NULL; > > > > > > > > > +void *digest = NULL; > > > > > > > > > +int desc_size; > > > > > > > > > +int digest_size; > > > > > > > > > +int ret = 0; > > > > > > > > > + > > > > > > > > > +tfm = crypto_alloc_shash("sha256", 0, 0); > > > > > > > > > +if (IS_ERR(tfm)) > > > > > > > > > +return PTR_ERR(tfm); > > > > > > > > Can we make the algorithm selectable via kernel parameter > > > > > > > > and/or writing > > > > > > > > to a new selinuxfs node? > > > > > > > I can add a kernel parameter to select this hash algorithm. > > > > > > Also can we provide a Kconfig option for the default value like IMA > > > > > > does? > > > > > > > > > > > Would we need both - Kconfig and kernel param? > > > > > > > > > > The other option is to provide an IMA function to return the current > > > > > hash algorithm used for measurement. That way a consistent hash > > > > > algorithm can be employed by both IMA and the callers. Would that be > > > > > better? > > > > This is why I preferred just passing the serialized policy buffer to > > > > IMA and letting it handle the hashing. But apparently that approach > > > > wouldn't fly. IMA appears to support both a Kconfig option for > > > > selecting a default algorithm and a kernel parameter for overriding > > > > it. I assume the idea is that the distros can pick a reasonable > > > > default and then the end users can override that if they have specific > > > > requirements. I'd want the same for SELinux. If IMA is willing to > > > > export its hash algorithm to external components, then I'm willing to > > > > reuse that but not sure if that's a layering violation. > > > With the new ima_measure_critical_data() hook, I agree with you and > > > Casey it doesn't make sense for each caller to have to write their own > > > function. Casey suggested exporting IMA's hash function or defining a > > > new common hash function. There's nothing specific to IMA. > > > > Except that no one is going to use the function unless they're > > doing an IMA operation. > > Can we do the following instead: > > In ima_measure_critical_data() IMA hook, we can add another param for > the caller to indicate whether > > => The contents of "buf" needs to be measured > OR > => Hash of the contents of "buf" needs to be measured. > > This way IMA doesn't need to export any new function to meet the hashing > requirement. I'm not sure overloading the parameters is a good idea, but extending ima_measure_critical_data() to calculate a simple buffer hash should be fine. Mimi
Re: [PATCH 2/2] SELinux: Measure state and hash of policy using IMA
On 8/17/20 3:00 PM, Casey Schaufler wrote: On 8/17/2020 2:31 PM, Mimi Zohar wrote: On Thu, 2020-08-13 at 14:13 -0400, Stephen Smalley wrote: On Thu, Aug 13, 2020 at 2:03 PM Lakshmi Ramasubramanian wrote: On 8/13/20 10:58 AM, Stephen Smalley wrote: On Thu, Aug 13, 2020 at 1:52 PM Lakshmi Ramasubramanian wrote: On 8/13/20 10:42 AM, Stephen Smalley wrote: diff --git a/security/selinux/measure.c b/security/selinux/measure.c new file mode 100644 index ..f21b7de4e2ae --- /dev/null +++ b/security/selinux/measure.c @@ -0,0 +1,204 @@ +static int selinux_hash_buffer(void *buf, size_t buf_len, + void **buf_hash, int *buf_hash_len) +{ +struct crypto_shash *tfm; +struct shash_desc *desc = NULL; +void *digest = NULL; +int desc_size; +int digest_size; +int ret = 0; + +tfm = crypto_alloc_shash("sha256", 0, 0); +if (IS_ERR(tfm)) +return PTR_ERR(tfm); Can we make the algorithm selectable via kernel parameter and/or writing to a new selinuxfs node? I can add a kernel parameter to select this hash algorithm. Also can we provide a Kconfig option for the default value like IMA does? Would we need both - Kconfig and kernel param? The other option is to provide an IMA function to return the current hash algorithm used for measurement. That way a consistent hash algorithm can be employed by both IMA and the callers. Would that be better? This is why I preferred just passing the serialized policy buffer to IMA and letting it handle the hashing. But apparently that approach wouldn't fly. IMA appears to support both a Kconfig option for selecting a default algorithm and a kernel parameter for overriding it. I assume the idea is that the distros can pick a reasonable default and then the end users can override that if they have specific requirements. I'd want the same for SELinux. If IMA is willing to export its hash algorithm to external components, then I'm willing to reuse that but not sure if that's a layering violation. With the new ima_measure_critical_data() hook, I agree with you and Casey it doesn't make sense for each caller to have to write their own function. Casey suggested exporting IMA's hash function or defining a new common hash function. There's nothing specific to IMA. Except that no one is going to use the function unless they're doing an IMA operation. Can we do the following instead: In ima_measure_critical_data() IMA hook, we can add another param for the caller to indicate whether => The contents of "buf" needs to be measured OR => Hash of the contents of "buf" needs to be measured. This way IMA doesn't need to export any new function to meet the hashing requirement. -lakshmi Should the common hash function be prefixed with "security_"? Yuck. That prefix is for interfaces that are exported outside the security sub-system. We're talking about a function that is provided for use within the security sub-system, but not for any one particular security module or non-module feature. We're currently using the lsm_ prefix for interfaces used within the security subsystem, so I suggest lsm_hash_brown_potatoes() might be the way to go. Like when we add a new security hook call, the new LSM call is separate from any other change. Please break up this patch with the SELinux specific pieces separated from the ima_measure_critical_data() call as much as possible.
Re: [PATCH 2/2] SELinux: Measure state and hash of policy using IMA
On 8/17/2020 2:31 PM, Mimi Zohar wrote: > On Thu, 2020-08-13 at 14:13 -0400, Stephen Smalley wrote: >> On Thu, Aug 13, 2020 at 2:03 PM Lakshmi Ramasubramanian >> wrote: >>> On 8/13/20 10:58 AM, Stephen Smalley wrote: On Thu, Aug 13, 2020 at 1:52 PM Lakshmi Ramasubramanian wrote: > On 8/13/20 10:42 AM, Stephen Smalley wrote: > >>> diff --git a/security/selinux/measure.c b/security/selinux/measure.c >>> new file mode 100644 >>> index ..f21b7de4e2ae >>> --- /dev/null >>> +++ b/security/selinux/measure.c >>> @@ -0,0 +1,204 @@ >>> +static int selinux_hash_buffer(void *buf, size_t buf_len, >>> + void **buf_hash, int *buf_hash_len) >>> +{ >>> +struct crypto_shash *tfm; >>> +struct shash_desc *desc = NULL; >>> +void *digest = NULL; >>> +int desc_size; >>> +int digest_size; >>> +int ret = 0; >>> + >>> +tfm = crypto_alloc_shash("sha256", 0, 0); >>> +if (IS_ERR(tfm)) >>> +return PTR_ERR(tfm); >> Can we make the algorithm selectable via kernel parameter and/or writing >> to a new selinuxfs node? > I can add a kernel parameter to select this hash algorithm. Also can we provide a Kconfig option for the default value like IMA does? >>> Would we need both - Kconfig and kernel param? >>> >>> The other option is to provide an IMA function to return the current >>> hash algorithm used for measurement. That way a consistent hash >>> algorithm can be employed by both IMA and the callers. Would that be better? >> This is why I preferred just passing the serialized policy buffer to >> IMA and letting it handle the hashing. But apparently that approach >> wouldn't fly. IMA appears to support both a Kconfig option for >> selecting a default algorithm and a kernel parameter for overriding >> it. I assume the idea is that the distros can pick a reasonable >> default and then the end users can override that if they have specific >> requirements. I'd want the same for SELinux. If IMA is willing to >> export its hash algorithm to external components, then I'm willing to >> reuse that but not sure if that's a layering violation. > With the new ima_measure_critical_data() hook, I agree with you and > Casey it doesn't make sense for each caller to have to write their own > function. Casey suggested exporting IMA's hash function or defining a > new common hash function. There's nothing specific to IMA. Except that no one is going to use the function unless they're doing an IMA operation. > Should > the common hash function be prefixed with "security_"? Yuck. That prefix is for interfaces that are exported outside the security sub-system. We're talking about a function that is provided for use within the security sub-system, but not for any one particular security module or non-module feature. We're currently using the lsm_ prefix for interfaces used within the security subsystem, so I suggest lsm_hash_brown_potatoes() might be the way to go. > > Like when we add a new security hook call, the new LSM call is separate > from any other change. Please break up this patch with the SELinux > specific pieces separated from the ima_measure_critical_data() call as > much as possible. > > thanks, > > Mimi >
Re: [PATCH 2/2] SELinux: Measure state and hash of policy using IMA
On Thu, 2020-08-13 at 14:13 -0400, Stephen Smalley wrote: > On Thu, Aug 13, 2020 at 2:03 PM Lakshmi Ramasubramanian > wrote: > > On 8/13/20 10:58 AM, Stephen Smalley wrote: > > > On Thu, Aug 13, 2020 at 1:52 PM Lakshmi Ramasubramanian > > > wrote: > > > > On 8/13/20 10:42 AM, Stephen Smalley wrote: > > > > > > > > > > diff --git a/security/selinux/measure.c b/security/selinux/measure.c > > > > > > new file mode 100644 > > > > > > index ..f21b7de4e2ae > > > > > > --- /dev/null > > > > > > +++ b/security/selinux/measure.c > > > > > > @@ -0,0 +1,204 @@ > > > > > > +static int selinux_hash_buffer(void *buf, size_t buf_len, > > > > > > + void **buf_hash, int *buf_hash_len) > > > > > > +{ > > > > > > +struct crypto_shash *tfm; > > > > > > +struct shash_desc *desc = NULL; > > > > > > +void *digest = NULL; > > > > > > +int desc_size; > > > > > > +int digest_size; > > > > > > +int ret = 0; > > > > > > + > > > > > > +tfm = crypto_alloc_shash("sha256", 0, 0); > > > > > > +if (IS_ERR(tfm)) > > > > > > +return PTR_ERR(tfm); > > > > > Can we make the algorithm selectable via kernel parameter and/or > > > > > writing > > > > > to a new selinuxfs node? > > > > > > > > I can add a kernel parameter to select this hash algorithm. > > > > > > Also can we provide a Kconfig option for the default value like IMA does? > > > > > > > Would we need both - Kconfig and kernel param? > > > > The other option is to provide an IMA function to return the current > > hash algorithm used for measurement. That way a consistent hash > > algorithm can be employed by both IMA and the callers. Would that be better? > > This is why I preferred just passing the serialized policy buffer to > IMA and letting it handle the hashing. But apparently that approach > wouldn't fly. IMA appears to support both a Kconfig option for > selecting a default algorithm and a kernel parameter for overriding > it. I assume the idea is that the distros can pick a reasonable > default and then the end users can override that if they have specific > requirements. I'd want the same for SELinux. If IMA is willing to > export its hash algorithm to external components, then I'm willing to > reuse that but not sure if that's a layering violation. With the new ima_measure_critical_data() hook, I agree with you and Casey it doesn't make sense for each caller to have to write their own function. Casey suggested exporting IMA's hash function or defining a new common hash function. There's nothing specific to IMA. Should the common hash function be prefixed with "security_"? Like when we add a new security hook call, the new LSM call is separate from any other change. Please break up this patch with the SELinux specific pieces separated from the ima_measure_critical_data() call as much as possible. thanks, Mimi
Re: [PATCH 2/2] SELinux: Measure state and hash of policy using IMA
On Thu, Aug 13, 2020 at 2:03 PM Lakshmi Ramasubramanian wrote: > > On 8/13/20 10:58 AM, Stephen Smalley wrote: > > On Thu, Aug 13, 2020 at 1:52 PM Lakshmi Ramasubramanian > > wrote: > >> > >> On 8/13/20 10:42 AM, Stephen Smalley wrote: > >> > diff --git a/security/selinux/measure.c b/security/selinux/measure.c > new file mode 100644 > index ..f21b7de4e2ae > --- /dev/null > +++ b/security/selinux/measure.c > @@ -0,0 +1,204 @@ > +static int selinux_hash_buffer(void *buf, size_t buf_len, > + void **buf_hash, int *buf_hash_len) > +{ > +struct crypto_shash *tfm; > +struct shash_desc *desc = NULL; > +void *digest = NULL; > +int desc_size; > +int digest_size; > +int ret = 0; > + > +tfm = crypto_alloc_shash("sha256", 0, 0); > +if (IS_ERR(tfm)) > +return PTR_ERR(tfm); > >>> Can we make the algorithm selectable via kernel parameter and/or writing > >>> to a new selinuxfs node? > >> > >> I can add a kernel parameter to select this hash algorithm. > > > > Also can we provide a Kconfig option for the default value like IMA does? > > > > Would we need both - Kconfig and kernel param? > > The other option is to provide an IMA function to return the current > hash algorithm used for measurement. That way a consistent hash > algorithm can be employed by both IMA and the callers. Would that be better? This is why I preferred just passing the serialized policy buffer to IMA and letting it handle the hashing. But apparently that approach wouldn't fly. IMA appears to support both a Kconfig option for selecting a default algorithm and a kernel parameter for overriding it. I assume the idea is that the distros can pick a reasonable default and then the end users can override that if they have specific requirements. I'd want the same for SELinux. If IMA is willing to export its hash algorithm to external components, then I'm willing to reuse that but not sure if that's a layering violation.
Re: [PATCH 2/2] SELinux: Measure state and hash of policy using IMA
On 8/13/20 10:58 AM, Stephen Smalley wrote: On Thu, Aug 13, 2020 at 1:52 PM Lakshmi Ramasubramanian wrote: On 8/13/20 10:42 AM, Stephen Smalley wrote: diff --git a/security/selinux/measure.c b/security/selinux/measure.c new file mode 100644 index ..f21b7de4e2ae --- /dev/null +++ b/security/selinux/measure.c @@ -0,0 +1,204 @@ +static int selinux_hash_buffer(void *buf, size_t buf_len, + void **buf_hash, int *buf_hash_len) +{ +struct crypto_shash *tfm; +struct shash_desc *desc = NULL; +void *digest = NULL; +int desc_size; +int digest_size; +int ret = 0; + +tfm = crypto_alloc_shash("sha256", 0, 0); +if (IS_ERR(tfm)) +return PTR_ERR(tfm); Can we make the algorithm selectable via kernel parameter and/or writing to a new selinuxfs node? I can add a kernel parameter to select this hash algorithm. Also can we provide a Kconfig option for the default value like IMA does? Would we need both - Kconfig and kernel param? The other option is to provide an IMA function to return the current hash algorithm used for measurement. That way a consistent hash algorithm can be employed by both IMA and the callers. Would that be better? -lakshmi
Re: [PATCH 2/2] SELinux: Measure state and hash of policy using IMA
On Thu, Aug 13, 2020 at 1:52 PM Lakshmi Ramasubramanian wrote: > > On 8/13/20 10:42 AM, Stephen Smalley wrote: > > >> diff --git a/security/selinux/measure.c b/security/selinux/measure.c > >> new file mode 100644 > >> index ..f21b7de4e2ae > >> --- /dev/null > >> +++ b/security/selinux/measure.c > >> @@ -0,0 +1,204 @@ > >> +static int selinux_hash_buffer(void *buf, size_t buf_len, > >> + void **buf_hash, int *buf_hash_len) > >> +{ > >> +struct crypto_shash *tfm; > >> +struct shash_desc *desc = NULL; > >> +void *digest = NULL; > >> +int desc_size; > >> +int digest_size; > >> +int ret = 0; > >> + > >> +tfm = crypto_alloc_shash("sha256", 0, 0); > >> +if (IS_ERR(tfm)) > >> +return PTR_ERR(tfm); > > Can we make the algorithm selectable via kernel parameter and/or writing > > to a new selinuxfs node? > > I can add a kernel parameter to select this hash algorithm. Also can we provide a Kconfig option for the default value like IMA does?
Re: [PATCH 2/2] SELinux: Measure state and hash of policy using IMA
On 8/13/20 10:42 AM, Stephen Smalley wrote: diff --git a/security/selinux/measure.c b/security/selinux/measure.c new file mode 100644 index ..f21b7de4e2ae --- /dev/null +++ b/security/selinux/measure.c @@ -0,0 +1,204 @@ +static int selinux_hash_buffer(void *buf, size_t buf_len, + void **buf_hash, int *buf_hash_len) +{ + struct crypto_shash *tfm; + struct shash_desc *desc = NULL; + void *digest = NULL; + int desc_size; + int digest_size; + int ret = 0; + + tfm = crypto_alloc_shash("sha256", 0, 0); + if (IS_ERR(tfm)) + return PTR_ERR(tfm); Can we make the algorithm selectable via kernel parameter and/or writing to a new selinuxfs node? I can add a kernel parameter to select this hash algorithm. -lakshmi
Re: [PATCH 2/2] SELinux: Measure state and hash of policy using IMA
On 8/13/20 1:07 PM, Lakshmi Ramasubramanian wrote: SELinux configuration and policy are some of the critical data for this security module that needs to be measured. This measurement can be used by an attestation service, for instance, to verify if the configuration and policies have been setup correctly and that they haven't been tampered with at runtime. Measure SELinux configuration, policy capabilities settings, and the hash of the loaded policy by calling the IMA hook ima_measure_critical_data(). Sample measurement of SELinux state and hash of the policy: 10 e32e...5ac3 ima-buf sha256:86e8...4594 selinux-state-1595389364:287899386 696e697469616c697a65643d313b656e61626c65643d313b656e666f7263696e673d303b636865636b72657170726f743d313b6e6574776f726b5f706565725f636f6e74726f6c733d313b6f70656e5f7065726d733d313b657874656e6465645f736f636b65745f636c6173733d313b616c776179735f636865636b5f6e6574776f726b3d303b6367726f75705f7365636c6162656c3d313b6e6e705f6e6f737569645f7472616e736974696f6e3d313b67656e66735f7365636c6162656c5f73796d6c696e6b733d303 10 9e81...0857 ima-buf sha256:4941...68fc selinux-policy-hash-1597335667:462051628 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). grep -m 1 "selinux-state" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | cut -d' ' -f 6 | xxd -r -p The output should be the list of key-value pairs. For example, initialized=1;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 For selinux-policy-hash, the hash of SELinux policy is included in the IMA log entry. 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 grep -m 1 "selinux-policy-hash" /sys/kernel/security/integrity/ima/ascii_runtime_measurements | cut -d' ' -f 6 Signed-off-by: Lakshmi Ramasubramanian Suggested-by: Stephen Smalley Reported-by: kernel test robot # error: implicit declaration of function 'vfree' Reported-by: kernel test robot # error: implicit declaration of function 'crypto_alloc_shash' Reported-by: kernel test robot # sparse: symbol 'security_read_selinux_policy' was not declared. Should it be static? --- diff --git a/security/selinux/measure.c b/security/selinux/measure.c new file mode 100644 index ..f21b7de4e2ae --- /dev/null +++ b/security/selinux/measure.c @@ -0,0 +1,204 @@ +static int selinux_hash_buffer(void *buf, size_t buf_len, + void **buf_hash, int *buf_hash_len) +{ + struct crypto_shash *tfm; + struct shash_desc *desc = NULL; + void *digest = NULL; + int desc_size; + int digest_size; + int ret = 0; + + tfm = crypto_alloc_shash("sha256", 0, 0); + if (IS_ERR(tfm)) + return PTR_ERR(tfm); Can we make the algorithm selectable via kernel parameter and/or writing to a new selinuxfs node?