Re: [PATCH bpf-next v1 00/13] MAC and Audit policy using eBPF (KRSI)

On 1/14/20 11:54 AM, Stephen Smalley wrote:

On 1/10/20 12:53 PM, Alexei Starovoitov wrote:

quoted

On Fri, Jan 10, 2020 at 04:27:58PM +0100, KP Singh wrote:

quoted

On 09-Jan 14:47, Stephen Smalley wrote:

quoted

On 1/9/20 2:43 PM, KP Singh wrote:

quoted

On 10-Jan 06:07, James Morris wrote:

quoted

On Thu, 9 Jan 2020, Stephen Smalley wrote:

quoted

On 1/9/20 1:11 PM, James Morris wrote:

quoted

On Wed, 8 Jan 2020, Stephen Smalley wrote:

quoted

The cover letter subject line and the Kconfig help text refer 
to it as a
BPF-based "MAC and Audit policy".  It has an enforce config 
option that
enables the bpf programs to deny access, providing access 
control. IIRC,
in
the earlier discussion threads, the BPF maintainers suggested 
that Smack
and
other LSMs could be entirely re-implemented via it in the 
future, and that
such an implementation would be more optimal.

In this case, the eBPF code is similar to a kernel module, 
rather than a
loadable policy file.  It's a loadable mechanism, rather than a 
policy, in
my view.

I thought you frowned on dynamically loadable LSMs for both 
security and
correctness reasons?

Based on the feedback from the lists we've updated the design for v2.

In v2, LSM hook callbacks are allocated dynamically using BPF
trampolines, appended to a separate security_hook_heads and run
only after the statically allocated hooks.

The security_hook_heads for all the other LSMs (SELinux, AppArmor etc)
still remains __lsm_ro_after_init and cannot be modified. We are still
working on v2 (not ready for review yet) but the general idea can be
seen here:

    
https://github.com/sinkap/linux-krsi/blob/patch/v1/trampoline_prototype/security/bpf/lsm.c 

quoted

Evaluating the security impact of this is the next step. My 
understanding
is that eBPF via BTF is constrained to read only access to hook
parameters, and that its behavior would be entirely restrictive.

I'd like to understand the security impact more fully, though.  
Can the
eBPF code make arbitrary writes to the kernel, or read anything 
other than
the correctly bounded LSM hook parameters?

As mentioned, the BPF verifier does not allow writes to BTF types.

quoted

quoted

And a traditional security module would necessarily fall
under GPL; is the eBPF code required to be likewise?  If not, 
KRSI is a
gateway for proprietary LSMs...

Right, we do not want this to be a GPL bypass.

This is not intended to be a GPL bypass and the BPF verifier checks
for license compatibility of the loaded program with GPL.

IIUC, it checks that the program is GPL compatible if it uses a 
function
marked GPL-only.  But what specifically is marked GPL-only that is 
required
for eBPF programs using KRSI?

Good point! If no-one objects, I can add it to the BPF_PROG_TYPE_LSM
specific verification for the v2 of the patch-set which would require
all BPF-LSM programs to be GPL.

I don't think it's a good idea to enforce license on the program.
The kernel doesn't do it for modules.
For years all of BPF tracing progs were GPL because they have to use
GPL-ed helpers to do anything meaningful.
So for KRSI just make sure that all helpers are GPL-ed as well.

IIUC, the example eBPF code included in this patch series showed a 
program that used a GPL-only helper for the purpose of reporting event 
output to userspace. But it could have just as easily omitted the use of 
that helper and still implemented its own arbitrary access control model 
on the LSM hooks to which it attached.  It seems like the question is 
whether the kernel developers are ok with exposing the entire LSM hook 
interface and all the associated data structures to non-GPLd code, 
irrespective of what helpers it may or may not use.

Also, to be clear, while kernel modules aren't necessarily GPL, prior to 
this patch series, all Linux security modules were necessarily GPLd in 
order to use the LSM interface.  So allowing non-GPL eBPF-based LSMs 
would be a change.