Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1430913
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Documenting ptrace access mode checking |
| Date | 2016-06-24 22:10 +0200 |
| Message-ID | <rNFAl-4mG-3@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <rMBp7-2Kp-11@gated-at.bofh.it> <rMW0x-7AM-1@gated-at.bofh.it> <rMXIZ-iE-13@gated-at.bofh.it> <rNuYh-5Mv-13@gated-at.bofh.it> <rNB3I-1gh-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, Jun 24, 2016 at 8:18 AM, Casey Schaufler <casey@schaufler-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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Documenting ptrace access mode checking "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-06-24 10:50 +0200
Re: Documenting ptrace access mode checking Casey Schaufler <casey@schaufler-ca.com> - 2016-06-24 17:20 +0200
Re: Documenting ptrace access mode checking Kees Cook <keescook@chromium.org> - 2016-06-24 22:10 +0200
Re: Documenting ptrace access mode checking "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-06-25 09:30 +0200
csiph-web