Messages in this thread | | | Subject | Re: [PATCH 2/2] SELinux: Measure state and hash of policy using IMA | From | Lakshmi Ramasubramanian <> | Date | Mon, 17 Aug 2020 15:33:15 -0700 |
| |
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@linux.microsoft.com> wrote: >>>> On 8/13/20 10:58 AM, Stephen Smalley wrote: >>>>> On Thu, Aug 13, 2020 at 1:52 PM Lakshmi Ramasubramanian >>>>> <nramas@linux.microsoft.com> 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. >>
| |