From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752693AbcFVVLp (ORCPT ); Wed, 22 Jun 2016 17:11:45 -0400 Received: from mail-wm0-f48.google.com ([74.125.82.48]:36206 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751432AbcFVVLl convert rfc822-to-8bit (ORCPT ); Wed, 22 Jun 2016 17:11:41 -0400 MIME-Version: 1.0 In-Reply-To: <86486234-d78a-234b-58bb-6ca646881dc6@gmail.com> References: <20160621205550.GA5191@pc.thejh.net> <86486234-d78a-234b-58bb-6ca646881dc6@gmail.com> From: Kees Cook Date: Wed, 22 Jun 2016 14:11:38 -0700 X-Google-Sender-Auth: il_vKxmDQ8yYyU-18kCM7JGvaDc Message-ID: Subject: Re: Documenting ptrace access mode checking To: "Michael Kerrisk (man-pages)" Cc: Jann Horn , James Morris , linux-man , Stephen Smalley , lkml , "Eric W. Biederman" , linux-security-module , Linux API , Casey Schaufler Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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; } -Kees -- Kees Cook Chrome OS & Brillo Security