From: Kees Cook <keescook@chromium.org>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: KP Singh <kpsingh@chromium.org>,
linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
linux-security-module@vger.kernel.org,
Brendan Jackman <jackmanb@google.com>,
Florent Revest <revest@google.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
James Morris <jmorris@namei.org>, Paul Turner <pjt@google.com>,
Jann Horn <jannh@google.com>,
Florent Revest <revest@chromium.org>,
Brendan Jackman <jackmanb@chromium.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH bpf-next v5 5/7] bpf: lsm: Initialize the BPF LSM hooks
Date: Mon, 23 Mar 2020 14:44:05 -0700 [thread overview]
Message-ID: <202003231354.1454ED92EC@keescook> (raw)
In-Reply-To: <0655d820-4c42-cf9a-23d3-82dc4fdeeceb@schaufler-ca.com>
On Mon, Mar 23, 2020 at 01:47:29PM -0700, Casey Schaufler wrote:
> On 3/23/2020 12:44 PM, Kees Cook wrote:
> > On Mon, Mar 23, 2020 at 05:44:13PM +0100, KP Singh wrote:
> >> +/* Some LSM hooks do not have 0 as their default return values. Override the
> >> + * __weak definitons generated by default for these hooks
> > If you wanted to avoid this, couldn't you make the default return value
> > part of lsm_hooks.h?
> >
> > e.g.:
> >
> > LSM_HOOK(int, -EOPNOTSUPP, inode_getsecurity, struct inode *inode,
> > const char *name, void **buffer, bool alloc)
>
> If you're going to do that you'll have to keep lsm_hooks.h and security.c
> default values in sync somehow. Note that the four functions you've called
> out won't be using call_int_hook() after the next round of stacking. I'm not
> nixing the idea, I just don't want the default return for the security_
> functions defined in two places.
Yeah, I actually went looking for this after I sent the email, realizing
that the defaults were also used in security.c. I've been pondering how
to keep them from being duplicated. I'm working on some ideas.
The four are:
inode_getsecurity
inode_setsecurity
task_prctl
xfrm_state_pol_flow_match
None of these are already just calling call_int_hook(), but I assume
they'll need further tweaks in the coming stacking.
To leave things as open-code-able as possible while still benefiting
from the macro consolidation, how about something like this:
lsm_hook_names.h:
LSM_HOOK(int, -EOPNOTSUPP, inode_getsecurity,
struct inode *inode, const char *name, void **buffer, bool alloc)
...
security.c:
#define LSM_RET_DEFAULT_void(DEFAULT, NAME) /* */
#define LSM_RET_DEFAULT_int(DEFAULT, NAME)
static const int NAME#_default = (DEFAULT);
#define LSM_HOOK(RET, DEFAULT, NAME, ...) \
LSM_RET_DEFAULT_#RET(DEFAULT, NAME)
#include <linux/lsm_hook_names.h>
#undef LSM_HOOK
...
Then -EOPNOTSUPP is available as "inode_getsecurity_default":
int security_inode_getsecurity(struct inode *inode, const char *name,
void **buffer, bool alloc)
{
struct security_hook_list *hp;
int rc;
if (unlikely(IS_PRIVATE(inode)))
return inode_getsecurity_default;
/*
* Only one module will provide an attribute with a given name.
*/
hlist_for_each_entry(hp, &security_hook_heads.inode_getsecurity, list) {
rc = hp->hook.inode_getsecurity(inode, name, buffer, alloc);
if (rc != inode_getsecurity_default)
return rc;
}
return inode_getsecurity_default;
}
On the other hand, it's only 4 non-default return codes, so maybe the
sync burden isn't very high?
--
Kees Cook
next prev parent reply other threads:[~2020-03-23 21:44 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-23 16:44 [PATCH bpf-next v5 0/8] MAC and Audit policy using eBPF (KRSI) KP Singh
2020-03-23 16:44 ` [PATCH bpf-next v5 1/7] bpf: Introduce BPF_PROG_TYPE_LSM KP Singh
2020-03-23 19:02 ` Yonghong Song
2020-03-23 16:44 ` [PATCH bpf-next v5 2/7] security: Refactor declaration of LSM hooks KP Singh
2020-03-23 19:33 ` Kees Cook
2020-03-23 19:56 ` Andrii Nakryiko
2020-03-24 16:06 ` KP Singh
2020-03-23 16:44 ` [PATCH bpf-next v5 3/7] bpf: lsm: provide attachment points for BPF LSM programs KP Singh
2020-03-23 19:04 ` Yonghong Song
2020-03-23 19:33 ` Kees Cook
2020-03-23 19:59 ` Andrii Nakryiko
2020-03-24 10:39 ` KP Singh
2020-03-24 16:12 ` KP Singh
2020-03-24 21:26 ` Andrii Nakryiko
2020-03-24 22:39 ` KP Singh
2020-03-23 16:44 ` [PATCH bpf-next v5 4/7] bpf: lsm: Implement attach, detach and execution KP Singh
2020-03-23 19:16 ` Yonghong Song
2020-03-23 19:44 ` KP Singh
2020-03-23 20:18 ` Andrii Nakryiko
2020-03-24 19:00 ` KP Singh
2020-03-24 14:35 ` Stephen Smalley
2020-03-24 14:50 ` KP Singh
2020-03-24 14:58 ` Stephen Smalley
2020-03-24 16:25 ` Casey Schaufler
2020-03-24 17:49 ` Stephen Smalley
2020-03-24 18:01 ` Kees Cook
2020-03-24 18:06 ` KP Singh
2020-03-24 18:21 ` Stephen Smalley
2020-03-24 18:27 ` KP Singh
2020-03-24 18:31 ` KP Singh
2020-03-24 18:34 ` Kees Cook
2020-03-24 18:33 ` Kees Cook
2020-03-23 16:44 ` [PATCH bpf-next v5 5/7] bpf: lsm: Initialize the BPF LSM hooks KP Singh
2020-03-23 19:44 ` Kees Cook
2020-03-23 19:47 ` KP Singh
2020-03-23 20:21 ` Andrii Nakryiko
2020-03-23 20:47 ` Casey Schaufler
2020-03-23 21:44 ` Kees Cook [this message]
2020-03-23 21:58 ` Casey Schaufler
2020-03-23 22:12 ` Kees Cook
2020-03-23 23:39 ` Casey Schaufler
2020-03-24 1:53 ` KP Singh
2020-03-25 14:35 ` KP Singh
2020-03-24 1:13 ` Casey Schaufler
2020-03-24 1:52 ` KP Singh
2020-03-24 14:37 ` Stephen Smalley
2020-03-24 14:42 ` KP Singh
2020-03-24 14:51 ` Stephen Smalley
2020-03-24 14:51 ` KP Singh
2020-03-24 17:57 ` Kees Cook
2020-03-23 16:44 ` [PATCH bpf-next v5 6/7] tools/libbpf: Add support for BPF_PROG_TYPE_LSM KP Singh
2020-03-23 19:21 ` Yonghong Song
2020-03-23 20:25 ` Andrii Nakryiko
2020-03-24 1:57 ` KP Singh
2020-03-23 16:44 ` [PATCH bpf-next v5 7/7] bpf: lsm: Add selftests " KP Singh
2020-03-23 20:04 ` Yonghong Song
2020-03-24 20:04 ` KP Singh
2020-03-24 23:54 ` Andrii Nakryiko
2020-03-25 0:36 ` KP Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202003231354.1454ED92EC@keescook \
--to=keescook@chromium.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=casey@schaufler-ca.com \
--cc=daniel@iogearbox.net \
--cc=gregkh@linuxfoundation.org \
--cc=jackmanb@chromium.org \
--cc=jackmanb@google.com \
--cc=jannh@google.com \
--cc=jmorris@namei.org \
--cc=kpsingh@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=pjt@google.com \
--cc=revest@chromium.org \
--cc=revest@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.