[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jJT2m0z-bDXjGb8dSmy=Qy1=1D8smdMBgKdJxRzwk327A@mail.gmail.com>
Date: Fri, 24 Jun 2016 13:07:13 -0700
From: Kees Cook <keescook@...omium.org>
To: Casey Schaufler <casey@...aufler-ca.com>
Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
Jann Horn <jann@...jh.net>, James Morris <jmorris@...ei.org>,
linux-man <linux-man@...r.kernel.org>,
Stephen Smalley <sds@...ho.nsa.gov>,
lkml <linux-kernel@...r.kernel.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
linux-security-module <linux-security-module@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>
Subject: Re: Documenting ptrace access mode checking
On Fri, Jun 24, 2016 at 8:18 AM, Casey Schaufler <casey@...aufler-ca.com> wrote:
> On 6/24/2016 1:40 AM, Michael Kerrisk (man-pages) wrote:
>> 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.
Just to fill in the history: prior the the recent LSM stacking changes
(v4.2), commoncap (which is effectively an LSM) was hard-coded to be
stacked with the single selected primary LSM. Then Yama got hard-coded
stacked with the primary LSM too, and then Casey saved us from total
insanity by providing a proper way to stack LSMs.
-Kees
--
Kees Cook
Chrome OS & Brillo Security
Powered by blists - more mailing lists