All of lore.kernel.org
 help / color / mirror / Atom feed
From: daniel@iogearbox.net (Daniel Borkmann)
To: linux-security-module@vger.kernel.org
Subject: [PATCH net-next 4/4] selinux: bpf: Add addtional check for bpf object file receive
Date: Thu, 05 Oct 2017 01:44:35 +0200	[thread overview]
Message-ID: <59D57263.3080601@iogearbox.net> (raw)
In-Reply-To: <20171004182932.140028-5-chenbofeng.kernel@gmail.com>

On 10/04/2017 08:29 PM, Chenbo Feng wrote:
> From: Chenbo Feng <fengc@google.com>
>
> Introduce a bpf object related check when sending and receiving files
> through unix domain socket as well as binder. It checks if the receiving
> process have privilege to read/write the bpf map or use the bpf program.
> This check is necessary because the bpf maps and programs are using a
> anonymous inode as their shared inode so the normal way of checking the
> files and sockets when passing between processes cannot work properly on
> eBPF object. This check only works when the BPF_SYSCALL is configured.

[...]
> +/* This function will check the file pass through unix socket or binder to see
> + * if it is a bpf related object. And apply correspinding checks on the bpf
> + * object based on the type. The bpf maps and programs, not like other files and
> + * socket, are using a shared anonymous inode inside the kernel as their inode.
> + * So checking that inode cannot identify if the process have privilege to
> + * access the bpf object and that's why we have to add this additional check in
> + * selinux_file_receive and selinux_binder_transfer_files.
> + */
[...]

If selinux/lsm folks have some input on this one in particular, would
be great. The issue is not really tied to bpf specifically, but to the
use of anon-inodes wrt fd passing. Maybe some generic resolution can
be found to tackle this ...
--
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

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Borkmann <daniel@iogearbox.net>
To: Chenbo Feng <chenbofeng.kernel@gmail.com>,
	netdev@vger.kernel.org, SELinux <Selinux@tycho.nsa.gov>,
	linux-security-module@vger.kernel.org
Cc: Jeffrey Vander Stoep <jeffv@google.com>,
	Lorenzo Colitti <lorenzo@google.com>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Chenbo Feng <fengc@google.com>
Subject: Re: [PATCH net-next 4/4] selinux: bpf: Add addtional check for bpf object file receive
Date: Thu, 05 Oct 2017 01:44:35 +0200	[thread overview]
Message-ID: <59D57263.3080601@iogearbox.net> (raw)
In-Reply-To: <20171004182932.140028-5-chenbofeng.kernel@gmail.com>

On 10/04/2017 08:29 PM, Chenbo Feng wrote:
> From: Chenbo Feng <fengc@google.com>
>
> Introduce a bpf object related check when sending and receiving files
> through unix domain socket as well as binder. It checks if the receiving
> process have privilege to read/write the bpf map or use the bpf program.
> This check is necessary because the bpf maps and programs are using a
> anonymous inode as their shared inode so the normal way of checking the
> files and sockets when passing between processes cannot work properly on
> eBPF object. This check only works when the BPF_SYSCALL is configured.

[...]
> +/* This function will check the file pass through unix socket or binder to see
> + * if it is a bpf related object. And apply correspinding checks on the bpf
> + * object based on the type. The bpf maps and programs, not like other files and
> + * socket, are using a shared anonymous inode inside the kernel as their inode.
> + * So checking that inode cannot identify if the process have privilege to
> + * access the bpf object and that's why we have to add this additional check in
> + * selinux_file_receive and selinux_binder_transfer_files.
> + */
[...]

If selinux/lsm folks have some input on this one in particular, would
be great. The issue is not really tied to bpf specifically, but to the
use of anon-inodes wrt fd passing. Maybe some generic resolution can
be found to tackle this ...

  reply	other threads:[~2017-10-04 23:44 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-04 18:29 [PATCH 0/4] net-next: security: New file mode and LSM hooks for eBPF object permission control Chenbo Feng
2017-10-04 18:29 ` Chenbo Feng
2017-10-04 18:29 ` [PATCH net-next 1/4] bpf: Add file mode configuration into bpf maps Chenbo Feng
2017-10-04 18:29   ` Chenbo Feng
2017-10-04 23:29   ` Daniel Borkmann
2017-10-04 23:29     ` Daniel Borkmann
2017-10-04 23:58     ` Chenbo Feng
2017-10-04 23:58       ` Chenbo Feng
2017-10-05  0:51       ` Daniel Borkmann
2017-10-05  0:51         ` Daniel Borkmann
2017-10-04 18:29 ` [PATCH net-next 2/4] security: bpf: Add LSM hooks for bpf object related syscall Chenbo Feng
2017-10-04 18:29   ` Chenbo Feng
2017-10-12  0:31   ` James Morris
2017-10-12  0:31     ` James Morris
2017-10-04 18:29 ` [PATCH net-next 3/4] selinux: bpf: Add selinux check for eBPF syscall operations Chenbo Feng
2017-10-04 18:29   ` Chenbo Feng
2017-10-05 13:28   ` Stephen Smalley
2017-10-05 13:28     ` Stephen Smalley
2017-10-05 16:12     ` Daniel Borkmann
2017-10-05 16:12       ` Daniel Borkmann
2017-10-04 18:29 ` [PATCH net-next 4/4] selinux: bpf: Add addtional check for bpf object file receive Chenbo Feng
2017-10-04 18:29   ` Chenbo Feng
2017-10-04 23:44   ` Daniel Borkmann [this message]
2017-10-04 23:44     ` Daniel Borkmann
2017-10-04 23:52     ` Daniel Borkmann
2017-10-04 23:52       ` Daniel Borkmann
2017-10-05 13:37   ` Stephen Smalley
2017-10-05 13:37     ` Stephen Smalley
2017-10-05 18:26     ` Stephen Smalley
2017-10-05 18:26       ` Stephen Smalley
2017-10-06 21:10       ` Chenbo Feng
2017-10-06 21:10         ` Chenbo Feng
2017-10-06 21:00     ` Chenbo Feng
2017-10-06 21:00       ` 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=59D57263.3080601@iogearbox.net \
    --to=daniel@iogearbox.net \
    --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 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.