Re: [PATCH 2/2] SELinux: Measure state and hash of policy using IMA
From: Lakshmi Ramasubramanian
Date: Mon Aug 17 2020 - 18:33:28 EST
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
<nramas@xxxxxxxxxxxxxxxxxxx> wrote:
On 8/13/20 10:58 AM, Stephen Smalley wrote:
On Thu, Aug 13, 2020 at 1:52 PM Lakshmi Ramasubramanian
<nramas@xxxxxxxxxxxxxxxxxxx> 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 000000000000..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.