On 27/08/2016 01:05, Alexei Starovoitov wrote: > On Fri, Aug 26, 2016 at 05:10:40PM +0200, Mickaël Salaün wrote: >> To sum up, there is four related patchsets: >> * "Landlock LSM: Unprivileged sandboxing" (this series) >> * "Add Checmate, BPF-driven minor LSM" (Sargun Dhillon) >> * "Networking cgroup controller" (Anoop Naravaram) >> * "Add eBPF hooks for cgroups" (Daniel Mack) >>> Anoop Naravaram's use case is to control the ports the applications >>> under cgroup can bind and listen on. >>> Such use case can be solved by such 'lsm cgroup controller' by >>> attaching bpf program to security_socket_bind lsm hook and >>> filtering sockaddr. >>> Furthermore Sargun's use case is to allow further sockaddr rewrites >>> from the bpf program which can be done as natural extension >>> of such mechanism. >>> >>> If I understood Daniel's Anoop's Sargun's and yours use cases >>> correctly the common piece of kernel infrastructure that can solve >>> them all can start from Daniel's current set of patches that >>> establish a mechanism of attaching bpf program to a cgroup. >>> Then adding lsm hooks to it and later allowing argument rewrite >>> (since they're already in the kernel and no ToCToU problems exist) >> For the network-related series, I think it make more sense to simply >> create a netfilter rule matching a cgroup and then add more features to >> netfilter (restrict port ranges and so on) thanks to eBPF programs. >> Containers are (usually) in a dedicated network namespace, which open >> the possibility to not only rely on cgroups (e.g. match UID, >> netmask...). It would also be more flexible to be able to load a BPF >> program in netfilter and update its maps on the fly to make dynamic >> rules, like ipset does, but in a more generic way. What do the netdev folks think about this design?