From: sds@tycho.nsa.gov (Stephen Smalley)
To: linux-security-module@vger.kernel.org
Subject: [PATCH net-next v2 4/5] selinux: bpf: Add selinux check for eBPF syscall operations
Date: Wed, 11 Oct 2017 09:00:09 -0400 [thread overview]
Message-ID: <1507726809.15898.6.camel@tycho.nsa.gov> (raw)
In-Reply-To: <CAMOXUJmKtpB6LU2V3AyBvMFizYDCrZGQ5ZG3+z=5FOyooQGy=w@mail.gmail.com>
On Tue, 2017-10-10 at 10:54 -0700, Chenbo Feng via Selinux wrote:
> On Tue, Oct 10, 2017 at 7:52 AM, Stephen Smalley <sds@tycho.nsa.gov>
> wrote:
> > On Tue, 2017-10-10 at 10:18 -0400, Stephen Smalley wrote:
> > > On Mon, 2017-10-09 at 15:20 -0700, Chenbo Feng wrote:
> > > > From: Chenbo Feng <fengc@google.com>
> > > >
> > > > Implement the actual checks introduced to eBPF related
> > > > syscalls.
> > > > This
> > > > implementation use the security field inside bpf object to
> > > > store a
> > > > sid that
> > > > identify the bpf object. And when processes try to access the
> > > > object,
> > > > selinux will check if processes have the right privileges. The
> > > > creation
> > > > of eBPF object are also checked at the general bpf check hook
> > > > and
> > > > new
> > > > cmd introduced to eBPF domain can also be checked there.
> > > >
> > > > Signed-off-by: Chenbo Feng <fengc@google.com>
> > > > Acked-by: Alexei Starovoitov <ast@kernel.org>
> > > > ---
> > > > ?security/selinux/hooks.c????????????| 111
> > > > ++++++++++++++++++++++++++++++++++++
> > > > ?security/selinux/include/classmap.h |???2 +
> > > > ?security/selinux/include/objsec.h???|???4 ++
> > > > ?3 files changed, 117 insertions(+)
> > > >
> > > > diff --git a/security/selinux/hooks.c
> > > > b/security/selinux/hooks.c
> > > > index f5d304736852..41aba4e3d57c 100644
> > > > --- a/security/selinux/hooks.c
> > > > +++ b/security/selinux/hooks.c
> > > > @@ -85,6 +85,7 @@
> > > > ?#include <linux/export.h>
> > > > ?#include <linux/msg.h>
> > > > ?#include <linux/shm.h>
> > > > +#include <linux/bpf.h>
> > > >
> > > > ?#include "avc.h"
> > > > ?#include "objsec.h"
> > > > @@ -6252,6 +6253,106 @@ static void
> > > > selinux_ib_free_security(void
> > > > *ib_sec)
> > > > ?}
> > > > ?#endif
> > > >
> > > > +#ifdef CONFIG_BPF_SYSCALL
> > > > +static int selinux_bpf(int cmd, union bpf_attr *attr,
> > > > +????????????????????????????????unsigned int size)
> > > > +{
> > > > +???u32 sid = current_sid();
> > > > +???int ret;
> > > > +
> > > > +???switch (cmd) {
> > > > +???case BPF_MAP_CREATE:
> > > > +???????????ret = avc_has_perm(sid, sid, SECCLASS_BPF_MAP,
> > > > BPF_MAP__CREATE,
> > > > +??????????????????????????????NULL);
> > > > +???????????break;
> > > > +???case BPF_PROG_LOAD:
> > > > +???????????ret = avc_has_perm(sid, sid, SECCLASS_BPF_PROG,
> > > > BPF_PROG__LOAD,
> > > > +??????????????????????????????NULL);
> > > > +???????????break;
> > > > +???default:
> > > > +???????????ret = 0;
> > > > +???????????break;
> > > > +???}
> > > > +
> > > > +???return ret;
> > > > +}
> > > > +
> > > > +static u32 bpf_map_fmode_to_av(fmode_t fmode)
> > > > +{
> > > > +???u32 av = 0;
> > > > +
> > > > +???if (f_mode & FMODE_READ)
> > > > +???????????av |= BPF_MAP__READ;
> > > > +???if (f_mode & FMODE_WRITE)
> > > > +???????????av |= BPF_MAP__WRITE;
> > > > +???return av;
> > > > +}
> > > > +
> > > > +static int selinux_bpf_map(struct bpf_map *map, fmode_t fmode)
> > > > +{
> > > > +???u32 sid = current_sid();
> > > > +???struct bpf_security_struct *bpfsec;
> > > > +
> > > > +???bpfsec = map->security;
> > > > +???return avc_has_perm(sid, bpfsec->sid, SECCLASS_BPF_MAP,
> > > > +???????????????????????bpf_map_fmode_to_av(fmode), NULL);
> > > > +}
> > > > +
> > > > +static int selinux_bpf_prog(struct bpf_prog *prog)
> > > > +{
> > > > +???u32 sid = current_sid();
> > > > +???struct bpf_security_struct *bpfsec;
> > > > +
> > > > +???bpfsec = prog->aux->security;
> > > > +???return avc_has_perm(sid, bpfsec->sid, SECCLASS_BPF_PROG,
> > > > +???????????????????????BPF_PROG__USE, NULL);
> > > > +}
> > > > +
> > > > +static int selinux_bpf_map_alloc(struct bpf_map *map)
> > > > +{
> > > > +???struct bpf_security_struct *bpfsec;
> > > > +
> > > > +???bpfsec = kzalloc(sizeof(*bpfsec), GFP_KERNEL);
> > > > +???if (!bpfsec)
> > > > +???????????return -ENOMEM;
> > > > +
> > > > +???bpfsec->sid = current_sid();
> > > > +???map->security = bpfsec;
> > > > +
> > > > +???return 0;
> > > > +}
> > > > +
> > > > +static void selinux_bpf_map_free(struct bpf_map *map)
> > > > +{
> > > > +???struct bpf_security_struct *bpfsec = map->security;
> > > > +
> > > > +???map->security = NULL;
> > > > +???kfree(bpfsec);
> > > > +}
> > > > +
> > > > +static int selinux_bpf_prog_alloc(struct bpf_prog_aux *aux)
> > > > +{
> > > > +???struct bpf_security_struct *bpfsec;
> > > > +
> > > > +???bpfsec = kzalloc(sizeof(*bpfsec), GFP_KERNEL);
> > > > +???if (!bpfsec)
> > > > +???????????return -ENOMEM;
> > > > +
> > > > +???bpfsec->sid = current_sid();
> > > > +???aux->security = bpfsec;
> > > > +
> > > > +???return 0;
> > > > +}
> > > > +
> > > > +static void selinux_bpf_prog_free(struct bpf_prog_aux *aux)
> > > > +{
> > > > +???struct bpf_security_struct *bpfsec = aux->security;
> > > > +
> > > > +???aux->security = NULL;
> > > > +???kfree(bpfsec);
> > > > +}
> > > > +#endif
> > > > +
> > > > ?static struct security_hook_list selinux_hooks[]
> > > > __lsm_ro_after_init
> > > > = {
> > > > ????LSM_HOOK_INIT(binder_set_context_mgr,
> > > > selinux_binder_set_context_mgr),
> > > > ????LSM_HOOK_INIT(binder_transaction,
> > > > selinux_binder_transaction),
> > > > @@ -6471,6 +6572,16 @@ static struct security_hook_list
> > > > selinux_hooks[] __lsm_ro_after_init = {
> > > > ????LSM_HOOK_INIT(audit_rule_match, selinux_audit_rule_match),
> > > > ????LSM_HOOK_INIT(audit_rule_free, selinux_audit_rule_free),
> > > > ?#endif
> > > > +
> > > > +#ifdef CONFIG_BPF_SYSCALL
> > > > +???LSM_HOOK_INIT(bpf, selinux_bpf),
> > > > +???LSM_HOOK_INIT(bpf_map, selinux_bpf_map),
> > > > +???LSM_HOOK_INIT(bpf_prog, selinux_bpf_prog),
> > > > +???LSM_HOOK_INIT(bpf_map_alloc_security,
> > > > selinux_bpf_map_alloc),
> > > > +???LSM_HOOK_INIT(bpf_prog_alloc_security,
> > > > selinux_bpf_prog_alloc),
> > > > +???LSM_HOOK_INIT(bpf_map_free_security,
> > > > selinux_bpf_map_free),
> > > > +???LSM_HOOK_INIT(bpf_prog_free_security,
> > > > selinux_bpf_prog_free),
> > > > +#endif
> > > > ?};
> > > >
> > > > ?static __init int selinux_init(void)
> > > > diff --git a/security/selinux/include/classmap.h
> > > > b/security/selinux/include/classmap.h
> > > > index 35ffb29a69cb..7253c5eea59c 100644
> > > > --- a/security/selinux/include/classmap.h
> > > > +++ b/security/selinux/include/classmap.h
> > > > @@ -237,6 +237,8 @@ struct security_class_mapping
> > > > secclass_map[] =
> > > > {
> > > > ??????{ "access", NULL } },
> > > > ????{ "infiniband_endport",
> > > > ??????{ "manage_subnet", NULL } },
> > > > +???{ "bpf_map", {"create", "read", "write"} },
> > > > +???{ "bpf_prog", {"load", "use"} },
> > >
> > > Again I have to ask: do you truly need/want two separate classes,
> > > or
> > > would a single class with distinct permissions suffice, ala:
> > > ????????{ "bpf", { "create_map", "read_map", "write_map",
> > > "prog_load",
> > > "prog_use" } },
> > >
> > > and then allow A self:bpf { create_map read_map write_map
> > > prog_load
> > > prog_use }; would be stored in a single policy avtab rule, and be
> > > cached in a single AVC entry.
>
> Sorry I missed to reply on this, I keep it that way because sometimes
> we need to grant the permission of accessing eBPF maps and programs
> separately. But keep them in a single class definitely works for me.
If we anticipated a large number of permissions being defined for
either bpf maps or programs, or if we were labeling them differently
(e.g. inheriting from creator for one, while using type transitions for
another), then it might make more sense to split the class (so that we
can support up to 32 distinct permissions for each one, or because we'd
never end up allowing both map and prog permissions to the same target
SID/context). But in this case I can't see any benefit to using two
classes, and it would consume more memory to do so.
BTW, please be sure to cc Paul Moore on these patches if you aren't
already since he is the selinux kernel tree maintainer.
> > I guess for consistency in naming it should be either:
> > ????????{ "bpf", { "map_create", "map_read", "map_write",
> > "prog_load",
> > "prog_use" } },
> >
> > or:
> >
> > ????????{ "bpf", { "create_map", "read_map", "write_map",
> > "load_prog",
> > "use_prog" } },
> >
> >
> > > > ????{ NULL }
> > > > ???};
> > > >
> > > > diff --git a/security/selinux/include/objsec.h
> > > > b/security/selinux/include/objsec.h
> > > > index 1649cd18eb0b..3d54468ce334 100644
> > > > --- a/security/selinux/include/objsec.h
> > > > +++ b/security/selinux/include/objsec.h
> > > > @@ -150,6 +150,10 @@ struct pkey_security_struct {
> > > > ????u32?????sid;????/* SID of pkey */
> > > > ?};
> > > >
> > > > +struct bpf_security_struct {
> > > > +???u32 sid;??/*SID of bpf obj creater*/
> > > > +};
> > > > +
> > > > ?extern unsigned int selinux_checkreqprot;
> > > >
> > > > ?#endif /* _SELINUX_OBJSEC_H_ */
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-10-11 13:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-09 22:20 [PATCH net-next v2 0/5] bpf: security: New file mode and LSM hooks for eBPF object permission control Chenbo Feng
2017-10-09 22:20 ` [PATCH net-next v2 1/5] bpf: Add file mode configuration into bpf maps Chenbo Feng
2017-10-09 23:07 ` Alexei Starovoitov
2017-10-09 23:31 ` Chenbo Feng
2017-10-09 22:20 ` [PATCH net-next v2 2/5] bpf: Add tests for eBPF file mode Chenbo Feng
2017-10-09 22:20 ` [PATCH net-next v2 3/5] security: bpf: Add LSM hooks for bpf object related syscall Chenbo Feng
2017-10-09 22:20 ` [PATCH net-next v2 4/5] selinux: bpf: Add selinux check for eBPF syscall operations Chenbo Feng
2017-10-10 14:18 ` Stephen Smalley
2017-10-10 14:52 ` Stephen Smalley
2017-10-10 17:54 ` Chenbo Feng
2017-10-11 13:00 ` Stephen Smalley [this message]
2017-10-10 17:59 ` kbuild test robot
2017-10-10 21:30 ` kbuild test robot
2017-10-09 22:20 ` [PATCH net-next v2 5/5] selinux: bpf: Add addtional check for bpf object file receive Chenbo Feng
2017-10-10 14:24 ` Stephen Smalley
2017-10-10 17:48 ` Chenbo Feng
2017-10-10 19:23 ` [Non-DoD Source] " Stephen Smalley
2017-10-10 19:42 ` Chenbo Feng
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=1507726809.15898.6.camel@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--cc=linux-security-module@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).