2017-04-27 17:18 GMT+02:00 Stephen Smalley [off-list ref]:

Ok, that should work as long as you just want to validate that all the
clients loaded the same policy file, and aren't concerned about non-
persistent policy boolean changes.

As far as I understand, non-persistent policy boolean changes can
affect the way the policy is enforced. So that is a problem if the
checksum does not reflect it. We want to protect against someone
tampering the policy locally on a Lustre client, even if it does not
survive a reboot.
I just checked, with the method of computing the checksum on a (data,
len) pair on entry to security_load_policy() the checksum does not
change after using setsebool. So it seems I would need to call
security_read_policy() to retrieve the binary representation of the
policy as currently enforced by the kernel. Unless you can see another
way?

You needed to get (global) enforcing mode too, didn't you?  That's
separate from the policy.

Exactly, I also need to rework the patch I proposed about this, in
light of the comments I received.

Make sure you make the hash algorithm explicit in both what is returned
by the hook to lustre and by what is exported via selinuxfs.  Can
likely just encode the hash algorithm name in the string when you
generate it.

Sure, I will add "sha256:" at the beginning of the string.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html