On 02/28/2018 12:55 AM, chris hyser wrote:
quoted
On 02/27/2018 04:58 PM, Daniel Borkmann wrote: >> On 02/27/2018 05:59 PM, chris hyser wrote:
quoted
quoted
On 02/27/2018 11:00 AM, Kees Cook wrote:
quoted
On Tue, Feb 27, 2018 at 6:53 AM, chris hyser [off-list ref] wrote:
quoted
On 02/26/2018 11:38 PM, Kees Cook wrote:
quoted
On Mon, Feb 26, 2018 at 8:19 PM, Andy Lutomirski [off-list ref]
wrote:
quoted
3. Straight-up bugs. Those are exactly as problematic as verifier
bugs in any other unprivileged eBPF program type, right? I don't see
why seccomp is special here.
My concern is more about unintended design mistakes or other feature
creep with side-effects, especially when it comes to privileges and
synchronization. Getting no-new-privs done correctly, for example,
took some careful thought and discussion, and I'm shy from how painful
TSYNC was on the process locking side, and eBPF has had some rather
ugly flaws in the past (and recently: it was nice to be able to say
for Spectre that seccomp filters couldn't be constructed to make
attacks but eBPF could). Adding the complexity needs to be worth the
Well, not really. One part of all the Spectre mitigations that went upstream
from BPF side was to have an option to remove interpreter entirely and that
also relates to seccomp eventually. But other than that an attacker might
potentially find as well useful gadgets inside seccomp or any other code
that is inside the kernel, so it's not a strict necessity either.
quoted
quoted
quoted
quoted
gain. I'm on board for doing it, I just want to be careful. :)
Another option might be to remove c/eBPF from the equation all together.
c/eBPF allows flexibility and that almost always comes at the cost of
additional security risk. Seccomp is for enhanced security yes? How about a
new seccomp mode that passes in something like a bit vector or hashmap for
"simple" white/black list checks validated by kernel code, versus user
provided interpreted code? Of course this removes a fair number of things
you can currently do or would be able to do with eBPF. Of course, restated
from a security point of view, this removes a fair number of things an
_attacker_ can do. Presumably the performance improvement would also be
significant.
Good luck with not breaking existing applications relying on seccomp out
there.
This wasn't in the context of an implementation proposal, but the assumption would be to add this in addition to the old way. Now, does that make sense to do? That is the discussion.
I see; didn't read that out from the above when you also mentioned removing
cBPF, but fair enough.
quoted
quoted
quoted
quoted
quoted
Is this an idea worth prototyping?
That was the original prototype for seccomp-filter. :) The discussion
around that from years ago basically boiled down to it being
inflexible. Given all the things people want to do at syscall time,
that continues to be true. So true, in fact, that here we are now,
trying to move to eBPF from cBPF. ;)
Right, agree. cBPF is also pretty much frozen these days and aside from
that, seccomp/BPF also just uses a proper subset of it. I wouldn't mind
doing something similar for eBPF side as long as this is reasonably
maintainable and not making BPF core more complex, but most of it can
already be set in the verifier anyway based on prog type. Note, that
performance of seccomp/BPF is definitely a demand as well which is why
people still extend the old remaining cBPF JITs today such that it can
be JITed also from there.
quoted
I will try to find that discussion. As someone pointed out here though, eBPF is being used by more and more people in areas where security is not the primary concern. Differing objectives will make this a long term continuing issue. We ourselves were looking at eBPF simply as a means to use a hashmap for a white/blacklist, i.e. performance not flexibility.
Not really, security of verifier and BPF infra in general is on the top
of the list, it's fundamental to the underlying concept and just because
it is heavily used also in tracing and networking, it only shows that the
concept is highly flexible that it can be applied in multiple areas.
If you're implying that because seccomp would have it's own verifier and could therefore restrict itself to a subset of eBPF, therefore any future additions/features to eBPF would not necessarily make seccomp less secure, I mainly agree. Is that the argument?
Ok, in addition to the current unpriv restrictions imposed by the verifier,
what additional requirements would you have from your side in order to get
to semantics that make sense for you wrt seccomp/eBPF? Just trying to
understand how far we are away from that. Note that not every new feature,
map or helper is enabled for every program type of course.
Thanks,
Daniel
-chrish
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers