From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754744AbdDLQVC (ORCPT ); Wed, 12 Apr 2017 12:21:02 -0400 Received: from smtp.nsa.gov ([8.44.101.8]:25974 "EHLO emsm-gh1-uea10.nsa.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752497AbdDLQU7 (ORCPT ); Wed, 12 Apr 2017 12:20:59 -0400 X-IronPort-AV: E=Sophos;i="5.37,191,1488844800"; d="scan'208";a="5885722" IronPort-PHdr: =?us-ascii?q?9a23=3AyARFZhxXXT3GarbXCy+O+j09IxM/srCxBDY+r6Qd?= =?us-ascii?q?0ugWIvad9pjvdHbS+e9qxAeQG96KtbQd1aGG7OjJYi8p2d65qncMcZhBBVcuqP?= =?us-ascii?q?49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6?= =?us-ascii?q?JvjvGo7Vks+7y/2+94fdbghMhTexe65+IRS5oQjStMQdnJdvJLs2xhbVuHVDZv?= =?us-ascii?q?5YxXlvJVKdnhb84tm/8Zt++ClOuPwv6tBNX7zic6s3UbJXAjImM3so5MLwrhnM?= =?us-ascii?q?URGP5noHXWoIlBdDHhXI4wv7Xpf1tSv6q/Z91SyHNsD4Ubw4RTKv5LpwRRT2lC?= =?us-ascii?q?kIKSI28GDPisxxkq1bpg6hpwdiyILQeY2ZKeZycr/Ycd4cS2VBRMJRXDFfDI26?= =?us-ascii?q?YYUEEu4NMf9Go4XholcDqwa1CwuxC+P10jJGhWL4060k3eovEw7G0gsgEM4Jvn?= =?us-ascii?q?vbo9v4L7sSXOOvwaXU1zjPc/Fb1DHg44bIaBAhpvSMUKptf8rN10YvDwPFgUuW?= =?us-ascii?q?qYf4Ij2V0/4Cs2yf7+V+VeOklmkqqxpsrTi03coslonIiZ4VylDD7yl5xp01Ks?= =?us-ascii?q?eiRE50Zt6kDoJduieHPIV1WsMvW3xktSk1x7EcuZO3YTIGxIooyhLBcfCLbo6F?= =?us-ascii?q?6Q/5WumLOzd3nndldaq6hxa17Eev1PXxVtKx0FZWtipFlcTMtmwV2xzT9MeHTv?= =?us-ascii?q?x981+92TmVzQDT6/xEIVsumarHK58u3r4wlp0JvUTFAiD2g1n5gLWTdkUl/uik?= =?us-ascii?q?8+XnYrP4qZ+AL4J4lw7zP6s0lsG/HOg0KBYCUmeF9eimybHv5Uj5T69Ljv0ynK?= =?us-ascii?q?nZqpfaJcEDq66iHgBVyZ0u6wq/Dji60NQYmmMLLFReeB2dlYTpNFbOIO7gAfel?= =?us-ascii?q?n1usiCtrx+zBPrD5AJXCNH3Dn6n6fbpn705Q0g8zzddF55JOC7EBO+n+WkjrtN?= =?us-ascii?q?PCEhA5NxK7z/z7B9V604MUQXiPDbOBMKPOrV+I4foiI/KXa48IuTb9MOMl5/no?= =?us-ascii?q?jXIihFASYK+p0YELZ3C/G/RsO1+Zbmb0gtcdDWcKuRIzTOjriF2ETD5SaG++X7?= =?us-ascii?q?ki6T4nFYKmF4bDRpytgbCY2Se7GYBZZn1CCl+SCnroaYqEVOkWaC6IIc9ujCYE?= =?us-ascii?q?Vb6/RI8lzx2usxX6y7V/JOrO5iIYrY7j1MRy5+DLkREy9Dp0D9mS0m2UTGF7gH?= =?us-ascii?q?kIRzko06B7ukF91FiD3rZig/BCFtxc+elJUgEkOp7Y1eB6DMryWg3ZdNeTVFmm?= =?us-ascii?q?WsmmAS02Tt8pzd4OYkJ9G9Gjjh/Z2iqmGaMam6aRBJwz6a3TwWLxJ9pmy3vd1a?= =?us-ascii?q?khiUUmTdVLNWG8mqF/8A3TDZbTk0qFj6aqabgc3CnV+WebyGqOu0ZYUBRuXqje?= =?us-ascii?q?R3AQeFbZrdTj6UPeVbOhFbMnMg5Zw86YNqRKcsHpjUlBRPr7I9TReH+xm2arBR?= =?us-ascii?q?aTwbOMapDmdHgA0yXbE0UEnAUT8myHNQg6HCuuv2XeDDk9XW7oNnjh++BltHK2?= =?us-ascii?q?SAce0gCRdEpnn+6u8AMUnuebTbUf0rQstyIoqjEyF1G4iYH4Ed2F8jF9cb1cbN?= =?us-ascii?q?V121JO0WbUpkQpJZC7B7xzjV4ZNQJstgXh0AshWdYIqtQjsH5/lFk6Eqmfyl4U?= =?us-ascii?q?MmrChZ0=3D?= X-IPAS-Result: =?us-ascii?q?A2F8BQCzUu5Y/wHyM5BcGwEBAQMBAQEJAQEBFwEBBAEBCgE?= =?us-ascii?q?Bgn8pgWyDZpo1AQEBAQEBBoEjkH2Ga4YkAoQBVwEBAQEBAQEBAgECaCiCMyIBg?= =?us-ascii?q?j8BAQEBAgEjDwFGEAsNAQoCAiYCAlcGE4gFggQFCKhogiYmAoppAQEBAQEFAQE?= =?us-ascii?q?BAQEjgQuFAIIjgxeHXIJfBY9xjRmSYYF/iH8MhjpIkzpYgQUcCQIUCB4PhzckN?= =?us-ascii?q?YkiAQEB?= Message-ID: <1492014294.3881.14.camel@tycho.nsa.gov> Subject: Re: [PATCH] selinux: add selinux_is_enforced() function From: Stephen Smalley To: Sebastien Buisson Cc: Paul Moore , selinux@tycho.nsa.gov, william.c.roberts@intel.com, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, Sebastien Buisson , james.l.morris@oracle.com Date: Wed, 12 Apr 2017 12:24:54 -0400 In-Reply-To: References: <1491988018-4120-1-git-send-email-sbuisson@ddn.com> <1492007701.3881.10.camel@tycho.nsa.gov> Organization: National Security Agency Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2017-04-12 at 17:11 +0200, Sebastien Buisson wrote: > 2017-04-12 16:35 GMT+02:00 Stephen Smalley : > > How are you using this SELinux information in the kernel and/or in > > userspace?  What's the purpose of it?  What are you comparing it > > against?  Why do you care if it changes? > > Enforcement status and policy version are compared to their > previously > stored value. If they differ, then it means we need to call a > userland > helper from Lustre client kernelspace to read the currently loaded > policy (reading it will let us know if the Lustre client node is > conforming to the Lustre-wide security policy). > As calling the userland helper is costly, we do it only when it is > necessary by retrieving some SELinux key information directly from > kernelspace. 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. > > > Note btw that the notion of a policy name/type and the policy file > > path > > is purely a userspace construct and shouldn't be embedded in your > > kernel code.  Android for example doesn't follow that convention at > > all; their SELinux policy file is simply /sepolicy.  On modern > > kernels, > > you can always read the currently loaded policy from the kernel > > itself > > via /sys/fs/selinux/policy (formerly just /selinux/policy). > > 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? In SELinux, the underlying kernel function is security_read_policy(); you'd have to wrap it with a LSM hook interface, and generalize it a bit wrt whether to use vmalloc_user() or not. 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 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: sds@tycho.nsa.gov (Stephen Smalley) Date: Wed, 12 Apr 2017 12:24:54 -0400 Subject: [PATCH] selinux: add selinux_is_enforced() function In-Reply-To: References: <1491988018-4120-1-git-send-email-sbuisson@ddn.com> <1492007701.3881.10.camel@tycho.nsa.gov> Message-ID: <1492014294.3881.14.camel@tycho.nsa.gov> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Wed, 2017-04-12 at 17:11 +0200, Sebastien Buisson wrote: > 2017-04-12 16:35 GMT+02:00 Stephen Smalley : > > How are you using this SELinux information in the kernel and/or in > > userspace???What's the purpose of it???What are you comparing it > > against???Why do you care if it changes? > > Enforcement status and policy version are compared to their > previously > stored value. If they differ, then it means we need to call a > userland > helper from Lustre client kernelspace to read the currently loaded > policy (reading it will let us know if the Lustre client node is > conforming to the Lustre-wide security policy). > As calling the userland helper is costly, we do it only when it is > necessary by retrieving some SELinux key information directly from > kernelspace. 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. > > > Note btw that the notion of a policy name/type and the policy file > > path > > is purely a userspace construct and shouldn't be embedded in your > > kernel code.??Android for example doesn't follow that convention at > > all; their SELinux policy file is simply /sepolicy.??On modern > > kernels, > > you can always read the currently loaded policy from the kernel > > itself > > via /sys/fs/selinux/policy (formerly just /selinux/policy). > > 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? In SELinux, the underlying kernel function is security_read_policy(); you'd have to wrap it with a LSM hook interface, and generalize it a bit wrt whether to use vmalloc_user() or not. 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 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. -- 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