IronPort-PHdr: =?us-ascii?q?9a23=3Ac8jF1h/bGu0Bdv9uRHKM819IXTAuvvDOBiVQ1KB+?=
 =?us-ascii?q?0OoRIJqq85mqBkHD//Il1AaPBtSFra4awLOM7ujJYi8p2d65qncMcZhBBVcuqP?=
 =?us-ascii?q?49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6?=
 =?us-ascii?q?JvjvGo7Vks+7y/2+94fdbghMhTexe7x/IRS5oQnMqMUbgZZpJ7osxBfOvnZGYf?=
 =?us-ascii?q?ldy3lyJVKUkRb858Ow84Bm/i9Npf8v9NNOXLvjcaggQrNWEDopM2Yu5M32rhbD?=
 =?us-ascii?q?VheA5mEdUmoNjBVFBRXO4QzgUZfwtiv6sfd92DWfMMbrQ704RSiu4qF2QxLzli?=
 =?us-ascii?q?wJKyA2/33WisxojaJUvhShpwBkw4XJZI2ZLedycr/Bcd8fQ2dOUNxRVyhcCY2i?=
 =?us-ascii?q?aYUBAfcKMeJBo4Xju1cCqB2zDhSuCuzy0D9Fnnz407A63eo/Hw/J3gIgH9USv3?=
 =?us-ascii?q?rTo9r7O7wfUfy2waTS0TnOde9a1DX75YPVch4hu/aMXbdofMTM1UkgCRvFjlWO?=
 =?us-ascii?q?pozjIjiby+ENvHKf7+pkS+2ui3MspgZqojey3cchkZXJh4IJxVDE8iV12oA1Jc?=
 =?us-ascii?q?aiR0Jhbt6kF4VQujicOoBrQc0iW3lltDs1x7AJo5K2fDUGxI45yxPQdfCLaZWE?=
 =?us-ascii?q?7xT+X+iLOzh4nmhqeLeniha39kiv1/PzW9Gv0FZPsipFit7Mtm0R1xDL6siIVP?=
 =?us-ascii?q?99/kC51DaTzQ/T8OBEIV0vlabBN54gwqI/lpoUsUjZGC/5hF72g7OMekUh++io?=
 =?us-ascii?q?7/zrYrTgppCCK495khzyP6shl8ClAek0LxICU3aU9OiizrHv4FX1QLBQgf03lq?=
 =?us-ascii?q?nZvoraJcMepqOhGA9az50j5g2jDzamzNsYnX4HIEhDeBKclYflIV7OIPfmDfun?=
 =?us-ascii?q?mVSjjC9rx+zaPr3mGpjNNWPMkKrgfbZm8E5czwwzwMtC6J1JDLENOu78Wkj0tN?=
 =?us-ascii?q?bAFB82LxS0w/r7CNV6zo4RRHiAAqmYMKzMtV+I5PkiI+ySa48RvDbyMf4l5/nh?=
 =?us-ascii?q?jHMjhVAdeqyp14MNaH+kBvRmP1mZYX30j9cZC2gKow4+QffyiFKYTD5TY2++X6?=
 =?us-ascii?q?c75jE8EoKpE53PSZyqgLyExC27BIFZZnhaClCQFnflb5uLW+8WZyKII89hiScJ?=
 =?us-ascii?q?VaC7RI871BGurxf6y759IeXI5CIUr5Xj1MJ65+fLjxE96SR0D9iB02GKV2x0nH?=
 =?us-ascii?q?kHRzoo06Bku0B9zk2P0a1/g/xCD9xT5uhJXxw9NZ7G1eN1F9TyVRzbctiVT1am?=
 =?us-ascii?q?R82sASstQdIp398Of0F9Fs25jh/dxSqqDKEamqeLBJMu9qLc23jwJ8Bnx3na06?=
 =?us-ascii?q?khikEsQtFTOm2+mq5/6w/TCpbNk0WYkaaqaKsd0DfO9Gid12qOul9XUAprXKXb?=
 =?us-ascii?q?UnAQeFHWoc765kzcVb+uD6ooMg9bxc6FMKtKZcXjjU9aS/f7JNTef2Wxln+0BR?=
 =?us-ascii?q?aJwLOMcYXrd3wG3CrDFEcEjhoT/XeaNQk+HyuhpmXeAyFzFVLrfUzh6vd+qHyl?=
 =?us-ascii?q?QU8u1Q2KbFNu16Cz+hELgfyQUfQT3qgLuC05sTV7AE69387KC9qHvwdhZ75TYc?=
 =?us-ascii?q?484FdczmLZsAp9Moa9IK9/gF4TaAt3v0b02BV2DoVMi9QlrHQvzFk6FaXN615L?=
 =?us-ascii?q?fiiE3J32cpfKK3Lp+xbnP7Xcx1DFy9GQvKsD7tw3rlziuEeiEU90oFt91NwA6G?=
 =?us-ascii?q?eR/pXHCkIpVJv1Vksmv0xhq6ryfjg254SS02Zld6azrGmRiJoSGOI5x0P4LJ9k?=
 =?us-ascii?q?O6SeGVq3SpdCCg=3D=3D?=
Message-ID: <1493318826.2524.21.camel@tycho.nsa.gov>
Subject: Re: [PATCH 2/3] selinux: add checksum to policydb
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Sebastien Buisson <sbuisson.ddn@gmail.com>
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 <eparis@parisplace.org>, Paul Moore <paul@paul-moore.com>,
        Daniel Jurgens <danielj@mellanox.com>,
        Sebastien Buisson <sbuisson@ddn.com>
Date: Thu, 27 Apr 2017 14:47:06 -0400
In-Reply-To: <CAPkE-bVo7BO4WypVoeTiNBkbva1touoG2f7KjC3-RgvFXe3FXg@mail.gmail.com>
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>
         <CAPkE-bVPHAGDX2uSt41UanVwiaJ3trCTgkUJiPNKNGKYVPMikw@mail.gmail.com>
         <1493306283.2524.17.camel@tycho.nsa.gov>
         <CAPkE-bVo7BO4WypVoeTiNBkbva1touoG2f7KjC3-RgvFXe3FXg@mail.gmail.com>
Organization: National Security Agency
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3056
Lines: 65

On Thu, 2017-04-27 at 19:12 +0200, Sebastien Buisson wrote:
> 2017-04-27 17:18 GMT+02:00 Stephen Smalley <sds@tycho.nsa.gov>:
> > 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.

A boolean change can affect which TE rules in the policy are
enabled/disabled, but only in ways that are defined by the original
policy.  You can't add arbitrary TE rules that way, just enable/disable
blocks that were defined conditionally in the policy.  It also has no
effect on MLS enforcement, for example.  So it depends on your goals.

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

I don't think that's a viable option, since security_read_policy() is
going to be expensive in order to generate a full policy image, while
security_set_bools() is supposed to be substantially cheaper than a
full policy load.

Also, the advantage of taking the hash of the original input file is
that you can independently compute a reference hash offline or on the
server from the same policy file and compare them and you can identify
which policy file was loaded based on the hash.

If you care about the active boolean state, then I'd suggest hashing
the active boolean state separately and storing that after the policy
hash.  You can do that in both security_load_policy() and
security_set_bools().  Just iterate through the bools like
security_set_bools() does, write the ->state of each boolean into a
buffer, and then hash that buffer.

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

So perhaps what you really want is a hook interface and a selinuxfs
interface that returns a single string that encodes all of the policy
properties that you care about?  Rather than separate hooks and
interfaces?  You could embed the enforcing status in the string too. 
Should probably include checkreqprot as well since that affects
enforcement of mmap/mprotect checks.

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