On 10-Jan 05:11, James Morris wrote:

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.

This would be similar to the difference between iptables rules and 
loadable eBPF networking code.  I'd be interested to know how the 
eBPF networking scenarios are handled wrt kernel ABI.

quoted

Again, not arguing for or against, but wondering if people fully understand
the implications.  If it ends up being useful, people will build access
control systems with it, and it directly exposes a lot of kernel internals to
userspace.  There was a lot of concern originally about the LSM hook interface
becoming a stable ABI and/or about it being misused.  Exposing that interface
along with every kernel data structure exposed through it to userspace seems
like a major leap.

Agreed this is a leap, although I'm not sure I'd characterize it as 
exposure to userspace -- it allows dynamic extension of the LSM API from 
userland, but the code is executed in the kernel.

KP: One thing I'd like to understand better is the attack surface 
introduced by this.  IIUC, the BTF fields are read only, so the eBPF code 
should not be able to modify any LSM parameters, correct?

That's correct, the verifier does not allow writes to BTF types:

from kernel/bpf/verifier.c:

        case PTR_TO_BTF_ID:
	if (type == BPF_WRITE) {
	        verbose(env, "Writes through BTF pointers are not allowed\n");
		return -EINVAL;
	}

We can also add additional checks on top of those added by the
verifier using the verifier_ops that each BPF program type can define. 

- KP

quoted

 Even if the mainline kernel doesn't worry about any kind
of stable interface guarantees for it, the distros might be forced to provide
some kABI guarantees for it to appease ISVs and users...

How is this handled currently for other eBPF use-cases?

-- 
James Morris
[off-list ref]