LWN：KRSI与propprietary BPF program！

关注了就能看到更多这么棒的文章哦～

KRSI and proprietary BPF programs

By Jonathan Corbet
January 17, 2020

原文来自：https://lwn.net/Articles/809841/

主译：https://www.deepl.com/translator

内核运行时安全注入(kernel runtime security instrumentation，KRSI) patch set可以将BPF program给挂载到内核中的所有security hook上。LWN在12月报道了这个工作。那篇文章主要关注了ABI问题，但它还有另一个潜在问题，我们在2020年的预测文章中有提到：厂商可能会开始发布专有的（proprietary）BPF program来用在KRSI等框架中。不过，其他开发者们确实也意识到了KRSI可能被这样滥用，因此导致了一场讨论，关于KRSI是否应该继续允许加载不兼容GPL license的BPF program。

可能许多人会感到惊讶，内核在允许BPF program来定义声明自己的license的同时，却完全不介意加载具有专有许可证（proprietary license）的BPF program。这种行为其实与内核处理loadable module的方式是一致的：任何内核module都允许加载，但是那些不兼容GPL的module将无法访问许多内核符号（即所有用EXPORT_SYMBOL_GPL()来export的内核符号）。BPF program通过特殊的 "helper function"来与内核进行交互，这些helper function都必须明确export出来，这些函数也有可能是标记为 "GPL only "的。在当前内核中，大约25%的helper function都只限GPL代码使用。

SELinux维护者Stephen Smalley首先提出了KRSI program的license问题。他说：

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.

（译文：传统的security module必然属于GPL的范畴；eBPF代码是否也需要同样的license？如果不是的话，KRSI就会变为proprietary LSM进来的一个渠道）

经过一番讨论后，KRSI开发者KP Singh建议在KRSI中添加一个明确的是否兼容GPL license的检查。这可以解决这个问题，但是Alexei Starovoitov反对这个改动，他说BPF program应该继续被当作loadable module来处理，这个方案只是确保了所有helper function都被标记为GPL-only。

但这个推理有一点问题，问题来自于BPF program在 KRSI 中的具体作用。虽然KRSI的开发者设想使用BPF program来完成系统范围内的各种监控任务，但这些BPF program本身也是作为security hook来发挥作用的。它们对传递到这些hook中的内核数据结构有完全的读取权限，最终它们负责返回一个布尔值，来标志这个操作是否应该被允许继续进行。有许多种类的安全策略可以直接在BPF中实现，根本不需要调用任何helper function。Smalley指出了这一点，并补充道：

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.

（译文：看来问题是内核开发者是否同意将整个LSM hook接口和所有相关的数据结构暴露给非GPL代码，这跟它用不用helper function并没有关系。）

不过Starovoitov并不担心这一点，他认为应该可以加载简单的非GPL程序：

Primitive KRSI progs like

    int bpf-prog(void*) { return REJECT; }

would be able to selectively disable a syscall with an overhead acceptable in production systems (unlike seccomp). I want this use case to be available to people. It's a bait, because to do real progs people would need to GPL them. Key helpers bpf_perf_event_output, bpf_ktime_get_ns, bpf_trace_printk are all GPL-ed. It may look that most networking helpers are not-GPL, but real life is different. To debug programs bpf_trace_printk() is necessary. To have communication with user space bpf_perf_event_output() is necessary. To measure anything or implement timestamps bpf_ktime_get_ns() is necessary.

So today all meaningful bpf programs are GPL. Those that are not GPL probably exist, but they're toy programs. Hence I have zero concerns about GPL bypass coming from tracing, networking, and, in the future, KRSI progs too.

（译文：类似这种KRSI基本程序将能够有选择地禁用一个系统调用，并且在生产系统中可以接受的开销（这与seccomp不同）。我希望这个使用场景大家能够接受。这是一个诱饵，因为要做真正有用的progs，人们需要把它GPL化。关键的helper函数，如bpf_perf_event_output、bpf_ktime_get_ns、bpf_trace_printk都是GPL的。可能看起来大多数的networking helper都不是GPL的，但实际上不是这样。在调试program的时候，bpf_trace_printk()是必要的。要与用户空间通信 的话，bpf_perf_event_output() 是必要的。要测量任何东西或实现时间戳的话，bpf_ktime_get_ns()是必需的。

所以今天所有有意义的bpf program都是GPL的。那些不是GPL的程序可能存在，但它们顶多算是玩具。因此，我完全不担心有人通过追踪、网络、以及将来的KRSI程序来绕过GPL。）

Smalley不以为然，他说："我预计那些没在kernel代码中维护的LSM的开发者们会利用这个bpf LSM来避开GPL限制。" Greg Kroah-Hartman也加入了谈话，支持Smalley："已经有许多公司试图采用类似这种的方法了，咱们不要给他们任何一种新的渠道来滥用我们的license"。Starovoitov投降了，他安慰自己说：反正今后大家发现这种担忧是不必要的时候，这个改动总归是可以 undo掉的。

这次讨论的结果，导致KRSI的第二版的时候增加了license check，尽管在changelog中没有提及这一点。这个版本还取消了基于 securityfs 的 API，转而使用 bpftool 工具来配置和反省(introspection)安全策略。

虽然对这个版本的patch set还有一些小讨论，但很可能现在merge的最大障碍已经被扫平了。其他的担那些担心——包括未来可能出现ABI相关的问题，以及允许将BPF program（拥有访问内部内核数据结构的权限和否决权）挂载到几乎所有用户空间可以操作到的地方——似乎并没有让很多人担心。因此，可以想象，KRSI在不久的将来可能会走向mainline。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注LWN深度文章以及开源社区的各种新近言论～