From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1163645AbdD0RNH (ORCPT ); Thu, 27 Apr 2017 13:13:07 -0400 Received: from mail-qk0-f195.google.com ([209.85.220.195]:34089 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S938352AbdD0RM6 (ORCPT ); Thu, 27 Apr 2017 13:12:58 -0400 MIME-Version: 1.0 In-Reply-To: <1493306283.2524.17.camel@tycho.nsa.gov> References: <1493218936-18522-1-git-send-email-sbuisson@ddn.com> <1493218936-18522-2-git-send-email-sbuisson@ddn.com> <1493231426.32540.11.camel@tycho.nsa.gov> <1493306283.2524.17.camel@tycho.nsa.gov> From: Sebastien Buisson Date: Thu, 27 Apr 2017 19:12:17 +0200 Message-ID: Subject: Re: [PATCH 2/3] selinux: add checksum to policydb To: Stephen Smalley Cc: linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, selinux@tycho.nsa.gov, serge@hallyn.com, james.l.morris@oracle.com, Eric Paris , Paul Moore , Daniel Jurgens , Sebastien Buisson Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2017-04-27 17:18 GMT+02:00 Stephen Smalley : > 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.