Re: [PATCH v3 4/5] LSM: Define SELinux function to measure security state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/20/20 11:44 AM, Stephen Smalley wrote:


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.


I can do the above.

 -lakshmi




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux