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.
> 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
>
