kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev
wings has joined #sandstorm
wings has left #sandstorm [#sandstorm]
<isd>
I made some progress on the bpf_asm based/whitelist seccomp filter today. It works well enough for yata to run, will test some more apps the next time I sit down. But at this point it's mostly a process of test & loosen restrictions as needed. It's disabled by default and can be turned on via a config option, my thinking is once we're not hitting obvious bugs in our own testing, we ship it and ask willing users to test it by
<isd>
manually enabling it. Eventually, when we're more confident, we'll make it the default, and then after enough time has passed, remove the old one (and the dependency on libseccomp)
<JacobWeisz[m]>
I like it. Between that and the client side loading, I feel like it may be a while until we can default everything, but at least we can test and offer people the ability to opt into the newer code.
<kentonv>
isd, oh nice, I really want to get rid of the libseccomp filter. We use bpf_asm in Workers and it's much nicer to deal with.
<kentonv>
incidentally we should probably adjust the existing filter to block all syscalls that are newer than whatever existed in 2016... new syscalls are more likely to have bugs...
<JacobWeisz[m]>
I noticed libseccomp is always excluded from updates. Is there breaking issues or is it left out for security?
<kentonv>
the way I integrated libseccomp into our build is weird, and every time they re-arrange their code it breaks. A while back they re-arranged their code and I didn't want to deal with it so I stopped updating it.
<kentonv>
you might argue this is risky given libseccomp is a security library -- but libseccomp does not process untrusted input, and in fact the way we use it, always processes exactly the same input, producing exactly the same output (a seccomp filter). The translation is pretty direct so there's not much room for it to go wrong.
<kentonv>
if we used bpf_asm instead, we'd actually be doing this step at build time
frigginglorious has joined #sandstorm
<isd>
kentonv: yeah, this changes it to a whitelist as well. I actually started with apatch that just did that, and found it annoying enough to write that I decided to just go all-in.
<isd>
But we should probably tack those on to the existing filter, since it will take a while before we can confidently make this the default.