From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751348AbcFXIkt (ORCPT ); Fri, 24 Jun 2016 04:40:49 -0400 Received: from mail-wm0-f46.google.com ([74.125.82.46]:38323 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750959AbcFXIkq (ORCPT ); Fri, 24 Jun 2016 04:40:46 -0400 Subject: Re: Documenting ptrace access mode checking To: Kees Cook References: <20160621205550.GA5191@pc.thejh.net> <86486234-d78a-234b-58bb-6ca646881dc6@gmail.com> Cc: mtk.manpages@gmail.com, Jann Horn , James Morris , linux-man , Stephen Smalley , lkml , "Eric W. Biederman" , linux-security-module , Linux API , Casey Schaufler From: "Michael Kerrisk (man-pages)" Message-ID: <7eee2029-4269-f9ab-78a7-341556f1350d@gmail.com> Date: Fri, 24 Jun 2016 10:40:39 +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/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. 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. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/