From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751353AbcFXPSe (ORCPT ); Fri, 24 Jun 2016 11:18:34 -0400 Received: from nm3-vm0.bullet.mail.bf1.yahoo.com ([98.139.212.154]:39968 "EHLO nm3-vm0.bullet.mail.bf1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750988AbcFXPSc (ORCPT ); Fri, 24 Jun 2016 11:18:32 -0400 X-Yahoo-Newman-Id: 67648.78984.bm@smtp234.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: bi.x.xAVM1kjq3hTu5Li7rBCzn.a6my.KZdk5LQ4DynK97c k8jGs0.Of0CN6YllRyi.o2HsS8yV.N2JoGx.x1CQIE1.QMLcCv0kC1wulZJ. oYdxWTk1DYd.KaMc3q2JkESiU7RLNVoW6n0I1_paLTBqQ0XkSKeH_43afHih BVksTqCElLueekJINCDrx0okQNjgnFh_zKeVPiq7CI1pBjzyhb3nyw3tXF8D WYFM0aPlkCFomG.I_TjM4wJHW2duO7jpPdCwHQE1Z330b70v5FSr23jj91sF e1wft8I1b6i8mABBjpDZd5ObFWyBfJsXOtPd69fy6QFbsMZMmi_IZz2unHyQ HYNruui2nkBTarFjhnXAahb2Md9oq91_lAv2vHqSfZ2faIpWl8_lh6ZeOZQ1 kIaLBH84rJX6B0DQ.lgoe..9KJfRtB8dp8eOZxTOy4U5ysVIkUmT_NIg4k5m W4vsgnPfo0IhGE60YYSp109iIX3JS3cWzowHRjvrxpZKhB1laPUKKEvbcpSB xIV2WppTefulBM4DLB7QpD83zglSeIzI7.PY25MOt4XhD2d2oubCWQPx4E9g - X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- Subject: Re: Documenting ptrace access mode checking To: "Michael Kerrisk (man-pages)" , Kees Cook References: <20160621205550.GA5191@pc.thejh.net> <86486234-d78a-234b-58bb-6ca646881dc6@gmail.com> <7eee2029-4269-f9ab-78a7-341556f1350d@gmail.com> Cc: Jann Horn , James Morris , linux-man , Stephen Smalley , lkml , "Eric W. Biederman" , linux-security-module , Linux API From: Casey Schaufler Message-ID: Date: Fri, 24 Jun 2016 08:18:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <7eee2029-4269-f9ab-78a7-341556f1350d@gmail.com> 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 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. > > Cheers, > > Michael > >