lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 4 Aug 2016 10:41:17 +0200
From:	Richard Weinberger <>
To:	Sargun Dhillon <>
Cc:	LKML <>,,
	Daniel Borkmann <>,
	LSM <>,
	"" <>
Subject: Re: [RFC 0/4] RFC: Add Checmate, BPF-driven minor LSM


On Thu, Aug 4, 2016 at 9:11 AM, Sargun Dhillon <> wrote:
> I distributed this patchset to 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?


Powered by blists - more mailing lists