Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935632AbdGTNmP (ORCPT ); Thu, 20 Jul 2017 09:42:15 -0400 Received: from mail-lf0-f65.google.com ([209.85.215.65]:36414 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934130AbdGTNmN (ORCPT ); Thu, 20 Jul 2017 09:42:13 -0400 MIME-Version: 1.0 X-Originating-IP: [108.49.102.27] In-Reply-To: References: <1500416736-49829-1-git-send-email-keescook@chromium.org> <1500416736-49829-5-git-send-email-keescook@chromium.org> From: Paul Moore Date: Thu, 20 Jul 2017 09:42:11 -0400 Message-ID: Subject: Re: [PATCH v3 04/15] selinux: Refactor to remove bprm_secureexec hook To: Kees Cook Cc: Stephen Smalley , Andrew Morton , David Howells , "Eric W. Biederman" , John Johansen , "Serge E. Hallyn" , Casey Schaufler , Tetsuo Handa , James Morris , Andy Lutomirski , Linus Torvalds , "linux-fsdevel@vger.kernel.org" , linux-security-module , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3198 Lines: 79 On Wed, Jul 19, 2017 at 9:37 PM, Kees Cook wrote: > On Wed, Jul 19, 2017 at 5:19 PM, Paul Moore wrote: >> On Wed, Jul 19, 2017 at 8:03 PM, Paul Moore wrote: >>> On Tue, Jul 18, 2017 at 6:25 PM, Kees Cook wrote: >>>> The SELinux bprm_secureexec hook can be merged with the bprm_set_creds >>>> hook since it's dealing with the same information, and all of the details >>>> are finalized during the first call to the bprm_set_creds hook via >>>> prepare_binprm() (subsequent calls due to binfmt_script, etc, are ignored >>>> via bprm->called_set_creds). >>>> >>>> Here, the test can just happen at the end of the bprm_set_creds hook, >>>> and the bprm_secureexec hook can be dropped. >>>> >>>> Cc: Paul Moore >>>> Cc: Stephen Smalley >>>> Signed-off-by: Kees Cook >>>> --- >>>> security/selinux/hooks.c | 24 +++++------------------- >>>> 1 file changed, 5 insertions(+), 19 deletions(-) >>> >>> This seems reasonable in the context of the other changes. >>> >>> Stephen just posted an AT_SECURE test for the selinux-testsuite on the >>> SELinux mailing list, it would be nice to ensure that this patchset >>> doesn't run afoul of that. >> >> Quick follow-up: I just merged Stephen's test into the test suite: >> >> * https://github.com/SELinuxProject/selinux-testsuite > > Is there a quick how-to on just running the AT_SECURE test? You'll need a functional SELinux system to start, I run it against Fedora Rawhide regularly* with various development kernels, but recent stable Fedora releases should work too. Occasionally I hear of people running it on Debian, but I haven't had a Debian SELinux system in some time so I can't say for certain everything is 100% working there. Once you've gotten a working system in enforcing mode, read the README file in the test suite to install the necessary dependencies (look in the "Userland and Base Policy" section), then build the tests/policy (you should be able to skip this step, as the make dependencies will handle it, but it is nice to do it separately to make sure you have the build dependencies sorted): # make ... load the test policy # make -C policy load ... run the tests: # cd tests/atsecure # ./test ... optionally uninstall the test policy: # make -C policy unload In some ways it is easier to just run the entire test suite: # make # make test Alternatively, if you've got a fairly recent git repo with all the patches merged I can build a test kernel and give it a shot for you, although fair warning it may take a day or two for me to get to it. * It is worth noting that the current 4.13-rcX releases have two bugs that affect the selinux-testsuite. The worst is a kernel panic due to a bug in overlayfs' xattr code, there is a patch available to fix it, but as of yesterday it hadn't yet hit Linus tree (I can dig it up if you need it). The second issue related to IPsec and getting peer label information over UDP connections, I haven't had a chance to sort that out yet, but at least it isn't a kernel panic. -- paul moore www.paul-moore.com