Sargun, On Thu, Aug 4, 2016 at 9:11 AM, Sargun Dhillon <sar...@sargun.me> wrote: > I distributed this patchset to linux-security-mod...@vger.kernel.org earlier, > but based on the fact that the archive is down, and this is a fairly > broad-sweeping proposal, I figured I'd grow the audience a little bit. Sorry > if you received this multiple times. > > I've begun building out the skeleton of a Linux Security Module, and I'd like > to > get feedback on it. It's a skeleton, and I've only populated a few hooks, so > I'm > mostly looking for input on the general proposal, interest, and design. It's a > minor LSM. My particular use case is one in which containers are being > dynamically deployed to machines by internal developers in a different group. > The point of Checmate is to act as an extensible bed for _safe_, complex > security policies. It's nice to enable dynamic security policies that can be > defined in C, and change as neccessary, without ever having to patch, or > rebuild > the kernel. > > For many of these containers, the security policies can be fairly nuanced. One > particular one to take into account is network security. Often times, > administrators want to prevent ingress, and egress connectivity except from a > few select IPs. Egress filtering can be managed using net_cls, but without > modifying running software, it's non-trivial to attach a filter to all sockets > being created within a container. The inet_conn_request, socket_recvmsg, > socket_sock_rcv_skb hooks make this trivial to implement.
What is wrong with having firewall rules per container? Either by matching the container IP or an interface... > Other times, containers need to be throttled in places where there's not > really > a good place to impose that policy for software which isn't built in-house. > If > one wants to limit file creations/sec, or reject I/O under certain > characteristics, there's not a great place to do it now. This gives engineers > a > mechanism to write those policies. Hmm, not sure if resource control is something we want to do with an LSM. > This same flexibility can be used to take existing programs and enable safe > BPF > helpers to modify memory to allow rules to pass. One example that I prototyped > was Docker's port mapping, which has an overhead (DNAT), and there's some loss > of fidelity in the BSD Socket API to identify what's going on. Instead, we can > just rewrite the port in a bind, based upon some data in a BPF map, and a > cgroup > match. > > I can actually see other minor security modules being implemented in Checmate, > for example, Yama, or the recently proposed Hardchroot could be reimplemented > in > BPF. Potentially, they could even be API compatible. > > Although, at first, much of this sounds like seccomp, it's quite different. > For > one, what we can do in the security hooks is more complex (access to kernel > pointers). The other side of this is we can have effects on a system-wide, > or cgroup level. This also circumvents the need for CRIU-friendly policies. It is like seccomp except that you have a single rule set and target LSM hooks instead of syscalls, right? -- Thanks, //richard