From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751317AbcFYH1y (ORCPT ); Sat, 25 Jun 2016 03:27:54 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:38778 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751133AbcFYH1w (ORCPT ); Sat, 25 Jun 2016 03:27:52 -0400 Subject: Re: Documenting ptrace access mode checking To: Casey Schaufler , Kees Cook References: <20160621205550.GA5191@pc.thejh.net> <86486234-d78a-234b-58bb-6ca646881dc6@gmail.com> <7eee2029-4269-f9ab-78a7-341556f1350d@gmail.com> Cc: mtk.manpages@gmail.com, Jann Horn , James Morris , linux-man , Stephen Smalley , lkml , "Eric W. Biederman" , linux-security-module , Linux API From: "Michael Kerrisk (man-pages)" Message-ID: <91afccbb-7ad0-040c-4171-ffacf98002d1@gmail.com> Date: Sat, 25 Jun 2016 09:21:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/24/2016 05:18 PM, Casey Schaufler wrote: > > > On 6/24/2016 1:40 AM, Michael Kerrisk (man-pages) wrote: >> On 06/22/2016 11:11 PM, Kees Cook wrote: >>> On Wed, Jun 22, 2016 at 12:21 PM, Michael Kerrisk (man-pages) >>> wrote: >>>> On 06/21/2016 10:55 PM, Jann Horn wrote: >>>>> On Tue, Jun 21, 2016 at 11:41:16AM +0200, Michael Kerrisk (man-pages) >>>>> wrote: >>>>>> 5. The kernel LSM security_ptrace_access_check() interface is >>>>>> invoked to see if ptrace access is permitted. The results >>>>>> depend on the LSM. The implementation of this interface in >>>>>> the default LSM performs the following steps: >>>>> >>>>> >>>>> For people who are unaware of how the LSM API works, it might be good to >>>>> clarify that the commoncap LSM is *always* invoked; otherwise, it might >>>>> give the impression that using another LSM would replace it. >>>> >>>> >>>> As we can see, I am one of those who are unaware of how the LSM API >>>> works :-/. >>>> >>>>> (Also, are there other documents that refer to it as "default LSM"? I >>>>> think that that term is slightly confusing.) >>>> >>>> >>>> No, that's a terminological confusion of my own making. Fixed now. >>>> >>>> I changed this text to: >>>> >>>> Various parts of the kernel-user-space API (not just ptrace(2) >>>> operations), require so-called "ptrace access mode permissions" >>>> which are gated by any enabled Linux Security Module (LSMs)—for >>>> example, SELinux, Yama, or Smack—and by the the commoncap LSM >>>> (which is always invoked). Prior to Linux 2.6.27, all such >>>> checks were of a single type. Since Linux 2.6.27, two access >>>> mode levels are distinguished: >>>> >>>> BTW, can you point me at the piece(s) of kernel code that show that >>>> "commoncap" is always invoked in addition to any other LSM that has >>>> been installed? >>> >>> It's not entirely obvious, but the bottom of security/commoncap.c shows: >>> >>> #ifdef CONFIG_SECURITY >>> >>> struct security_hook_list capability_hooks[] = { >>> LSM_HOOK_INIT(capable, cap_capable), >>> ... >>> }; >>> >>> void __init capability_add_hooks(void) >>> { >>> security_add_hooks(capability_hooks, ARRAY_SIZE(capability_hooks)); >>> } >>> >>> #endif >>> >>> And security/security.c shows the initialization order of the LSMs: >>> >>> int __init security_init(void) >>> { >>> pr_info("Security Framework initialized\n"); >>> >>> /* >>> * Load minor LSMs, with the capability module always first. >>> */ >>> capability_add_hooks(); >>> yama_add_hooks(); >>> loadpin_add_hooks(); >>> >>> /* >>> * Load all the remaining security modules. >>> */ >>> do_security_initcalls(); >>> >>> return 0; >>> } >> >> So, I just want to check my understanding of a couple of points: >> >> 1. The commoncap LSM is invoked first, and if it denies access, >> then no further LSM is/needs to be called. > > Yes. The LSM infrastructure is "bail on fail". > >> >> 2. Is it the case that only one of the other LSMs (SELinux, Yama, >> AppArmor, etc.) is invoked, or can more than one be invoked. >> I thought only one is invoked, but perhaps I am out of date >> in my understanding. > > All registered modules are invoked, but only one "major" > module can be registered. The "minor" modules show up in > security_init, while the majors come in via do_security_initcalls. > > I am in the process of messing that all up with patches > allowing multiple major modules. Stay tuned. Thanks for the info, Casey. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/