Re: Documenting ptrace access mode checking
From: Michael Kerrisk (man-pages)
Date: Sat Jun 25 2016 - 03:28:09 EST
On 06/24/2016 05:18 PM, Casey Schaufler wrote:
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)
<mtk.manpages@xxxxxxxxx> 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.
Thanks for the info, Casey.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/