From: Daniel Borkmann <daniel@iogearbox.net>
To: Sargun Dhillon <sargun@sargun.me>, linux-kernel@vger.kernel.org
Cc: alexei.starovoitov@gmail.com,
linux-security-module@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [RFC 0/4] RFC: Add Checmate, BPF-driven minor LSM
Date: Thu, 04 Aug 2016 11:45:08 +0200 [thread overview]
Message-ID: <57A30EA4.8010400@iogearbox.net> (raw)
In-Reply-To: <20160804071116.GA19098@ircssh.c.rugged-nimbus-611.internal>
Hi Sargun,
On 08/04/2016 09:11 AM, Sargun Dhillon wrote:
[...]
> [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.
[...]
> 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.
I'm not too familiar with LSMs, but afaik, when you install such policies they
are effectively global, right? How would you install/manage such policies per
container?
On a quick glance, this would then be the job of the BPF proglet from the global
hook, no? If yes, then the BPF contexts the BPF prog works with seem rather quite
limited ...
+struct checmate_file_open_ctx {
+ struct file *file;
+ const struct cred *cred;
+};
+
+struct checmate_task_create_ctx {
+ unsigned long clone_flags;
+};
+
+struct checmate_task_free_ctx {
+ struct task_struct *task;
+};
+
+struct checmate_socket_connect_ctx {
+ struct socket *sock;
+ struct sockaddr *address;
+ int addrlen;
+};
... or are you using bpf_probe_read() in some way to walk 'current' to retrieve
a namespace from there somehow? Like via nsproxy? But how you make sense of this
for defining a per container policy?
Do you see a way where we don't need to define so many different ctx each time?
My other concern from a security PoV is that when using things like bpf_probe_read()
we're dependent on kernel structs and there's a risk that when people migrate such
policies that expectations break due to underlying structs changed. I see you've
addressed that in patch 4 to place a small stone in the way, yeah kinda works. It's
mostly a reminder that this is not stable ABI.
Thanks,
Daniel
next prev parent reply other threads:[~2016-08-04 9:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-04 7:11 [RFC 0/4] RFC: Add Checmate, BPF-driven minor LSM Sargun Dhillon
2016-08-04 8:41 ` Richard Weinberger
2016-08-04 9:24 ` Sargun Dhillon
2016-08-04 9:45 ` Daniel Borkmann [this message]
2016-08-04 10:12 ` Sargun Dhillon
2016-08-08 23:44 ` Kees Cook
2016-08-09 0:00 ` Sargun Dhillon
2016-08-09 0:22 ` Kees Cook
2016-08-14 22:57 ` Mickaël Salaün
2016-08-15 3:09 ` Sargun Dhillon
2016-08-15 10:59 ` Mickaël Salaün
2016-08-15 17:03 ` Sargun Dhillon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57A30EA4.8010400@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=alexei.starovoitov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sargun@sargun.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).