IronPort-PHdr: =?us-ascii?q?9a23=3A6OvmjRDP57J7z4241gc3UyQJP3N1i/DPJgcQr6Af?=
 =?us-ascii?q?oPdwSP35o8qwAkXT6L1XgUPTWs2DsrQf2rSQ6v6rCTNIyK3CmUhKSIZLWR4BhJ?=
 =?us-ascii?q?detC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+?=
 =?us-ascii?q?KPjrFY7OlcS30P2594HObwlSijewZbJ/IA+roQjQucUbgolvIbstxxXUpXdFZ/?=
 =?us-ascii?q?5Yzn5yK1KJmBb86Maw/Jp9/ClVpvks6c1OX7jkcqohVbBXAygoPG4z5M3wqBnM?=
 =?us-ascii?q?VhCP6WcGUmUXiRVHHQ7I5wznU5jrsyv6su192DSGPcDzULs5Vyiu47ttRRT1ky?=
 =?us-ascii?q?oMKSI3/3/LhcxxlKJboQyupxpjw47PfYqZMONycr7Bcd8GQGZMWMheVzZFAoih?=
 =?us-ascii?q?cYUBCeQPNvtco4XkulcCsR6yCA+xD+3t1zBInGf7064n3eohDw/I0g4vH9wJsH?=
 =?us-ascii?q?vIq9v6O6gcXPupzKTL1zjPc+lb1Sv/5YXObxsvoeuMXbV1ccfJ1EcvCx3Kjk2Q?=
 =?us-ascii?q?qYP7OTOey/kDs22B4OpkUeKglW4moBx2rzi028gskZLEhp4Vy1/Y9SV5x5w5Jd?=
 =?us-ascii?q?ujSEFhe9KkH5xQtz+DOoZwX8gsTWZouCMgxb0Hv562ZCsKx4o9xx7ZdfOHd5KE?=
 =?us-ascii?q?4hX5VOaeJzpzmXFreKqnihqv/kWtxffwW8mp3FpQsCZIncfAumoQ2xHV98OJUO?=
 =?us-ascii?q?Fy/l271jaKzw3T7+ZELl0qmqfDMJ4hx6IwloIUsUTeAi/6gEX2g7GSdkUj4uWo?=
 =?us-ascii?q?9/7oYq/npp+BLI94kB3+M6Qylcy/BuQ0KA4OUHSA+eugzrHj+Ez5QLFSgv03lK?=
 =?us-ascii?q?nWrozaKNwGqqO2DAJZyIYu5wulAzu439kUg2MLIE9ddBKClYfpOlXOIP7iDfe4?=
 =?us-ascii?q?hlShiCxryO3dPrD6HpXMLmTMkLfmfbpn7U5c0xA8wcpQ55JTFLENOOjzVVPptN?=
 =?us-ascii?q?zEEh85NBS5w+T9B9V4yIweQniDAquDPKPXtl+I/PgvI+iXZIIOvzb9MeIq6OLq?=
 =?us-ascii?q?jXAng1MSYa6p3Z4PYnCiAvtmO1mZYWbrgtoZCmcFpRc+TO3xiF2ZVj5TYW2/UL?=
 =?us-ascii?q?8h6TE9Eo6pEYDDRoW1irybwCi7BoFWZnxBCl2UFXfodoOEW+oDaS6LOc9ujCAL?=
 =?us-ascii?q?VaW7S48gyRGvtBb2y79gLuXJ5y0YsYzs2cNr5+3cix4y7yZ4D8eD3GGXSWF7gG?=
 =?us-ascii?q?cISyUx3KBlrkx30k2D3rRgg/xECdxT4OtEUgM7NZ7a0ux7BMn+WgHfcdeTTlap?=
 =?us-ascii?q?XNGmDCovTtI+3dAOeVxxG9a8gRDZ2SqlHbsVm6aMBJwu/aLWx2LxKNply3bayK?=
 =?us-ascii?q?khiEErQ8VONW2igq5/9hLcB4vTn0qFjaqqb6Mc0zXT+2eZ0WqOp1pVUA92UaXZ?=
 =?us-ascii?q?Q38fYlHaosj+5kPHV7WuE6goMhNdyc6eLatHcsXpjVBBRPfkItTRfXm8m32uCh?=
 =?us-ascii?q?mVxrODdpbqd38B0yXaDUgOixoT8mqeNQgiGiehpHrTDCd1GlLyYkPs6vJ+qHS9?=
 =?us-ascii?q?TkMu0g6Fckth2qG6+h4Qn/OcSvcT0qgYtycmrjUnVGq6iunbAdObuwtseu12fN?=
 =?us-ascii?q?Im+1BBnTbCvRF8JYenKeZuilg2fAF+vkeo3BJyXNZui88v+Ug2wRJyJKTQ61ZI?=
 =?us-ascii?q?czeVzNikIbHMAnXj9xCoLajN0xfR18jAqfRH0+gxt1i25FLhLUEl6XgyloAMi3?=
 =?us-ascii?q?Y=3D?=
Message-ID: <1492017895.3881.18.camel@tycho.nsa.gov>
Subject: Re: [PATCH] selinux: add selinux_is_enforced() function
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Sebastien Buisson <sbuisson.ddn@gmail.com>
Cc: Paul Moore <pmoore@redhat.com>, selinux@tycho.nsa.gov,
        william.c.roberts@intel.com, linux-kernel@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        Sebastien Buisson <sbuisson@ddn.com>, james.l.morris@oracle.com
Date: Wed, 12 Apr 2017 13:24:55 -0400
In-Reply-To: <CAPkE-bWrxxtcb5bUpSV07CUBGGxMt7y+OrAd9Qvk0o4-Lo26VA@mail.gmail.com>
References: <1491988018-4120-1-git-send-email-sbuisson@ddn.com>
         <CAGH-KgsymFfRqDnmn1kLpWiPtHFkLU3UMKVu=8=NOUwk+qWjmg@mail.gmail.com>
         <CAPkE-bX5-Mo9AMPwf6dwBNT9FeWgAShWwKbkiJg3ZZVpt9itLA@mail.gmail.com>
         <1492007701.3881.10.camel@tycho.nsa.gov>
         <CAPkE-bWQLfSq0+J0uoMRKAPbSdO0giuGZzfRXA7VXL+xo3fNgg@mail.gmail.com>
         <1492014294.3881.14.camel@tycho.nsa.gov>
         <CAPkE-bWrxxtcb5bUpSV07CUBGGxMt7y+OrAd9Qvk0o4-Lo26VA@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: 2314
Lines: 56

On Wed, 2017-04-12 at 19:07 +0200, Sebastien Buisson wrote:
> 2017-04-12 18:24 GMT+02:00 Stephen Smalley <sds@tycho.nsa.gov>:
> > Maybe you want to register a notifier callback on policy reload?
> > See
> > the archives for the SELinux support for Infiniband RDMA patches
> > (which
> > seem to have stalled), which included LSM hooks and SELinux
> > implementation to support notifications on policy reloads.
> 
> I need to have a look indeed. So it is a callback in kernelspace?

Yes, see:
https://patchwork.kernel.org/patch/9443417/

> 
> > > As I understand it, a userspace program can directly read the
> > > policy
> > > info exposed by the kernel by reading this file. But how about
> > > reading it from kernelspace?
> > 
> > This seems very inefficient though for your purposes.  Wouldn't it
> > be
> > better to just extend SELinux to compute the checksum from the
> > original
> > image when the policy is loaded, save that checksum in the
> > policydb,
> > and provide you with a way to fetch the already computed
> > checksum?  The
> > computation would be done in security_load_policy() and saved in
> > the
> > policydb.  Then you could introduce a function and a LSM hook to
> > export
> > it to your code. We would probably want to also expose it via a
> > selinuxfs node to userspace.
> 
> This is an excellent suggestion. It makes much more sense to have the
> checksum computed on SELinux side when a policy is loaded. And then
> just read this checksum when needed, both from kernel and userspace.
>
> > This however only works for checking that you have a completely
> > identical policy built in exactly the same way.  You could have
> > semantically identical policies that still differ in the binary
> > policy
> > file, or policies with minor local customizations that aren't
> > significant.  But perhaps that isn't an issue for Lustre
> > environments.
> 
> If we can protect against local customizations this is great. What
> could be the other scenario leading to different binary policies
> while
> being semantically identical?

There can be ordering or optimization differences, depending on the
policy compiler toolchain and build process. Probably not a concern if
they are all running the same distro with the same policy package,
built in the same build environment.