<blowfist>
libera.chat started just yesterday I believe, it's still quite amazing how fast they set that up
<blowfist>
makes me remember a bit the story with the creation of git :)
<isd>
It's almost like they've set up IRC servers before :P
<blowfist>
well the IR servers is one thing but the website as well which is suprisingly well designed
<blowfist>
isd: will be get an IRC server in sandstorm? If we had, we could have taken over freenode ;P
<blowfist>
isd: btw is there any plans for arm and aarch64 in sandstorm?
<blowfist>
although I don't think having multiple arch support in packages would be a good idea... they are already quite big
<JacobWeisz[m]>
I mean, with all their letters pre-drafted, my guess is at least a few of them were prepping this stuff pre-announcement.
<JacobWeisz[m]>
Don't go nuclear without an exit strategy. Libera folks did their homework.
<blowfist>
I'll say like isd : It's almost like they've had insider info ;P
<JacobWeisz[m]>
blowfist: It definitely is in the "would like to" category, Sandstorm would get a huge boost if people could run it on ARM boards, especially now that things like the RPi 4 can be bought with RAM that isn't literally a joke.
<JacobWeisz[m]>
But at current resource levels, it's hard to imagine a near future time that would happen, because in addition to the platform support itself, we'd need to create/maintain packages that supported those architectures, and tbh, it'd be nice if our x64 packages got more love and attention sometimes.
<blowfist>
hmm, although eventually arm could get x86_64 emulation/dynarec support eventually and that would greatly lift the porting weight
<isd>
I'd definitley like to get to supporting arm64. But, it's a long road and not necessarily high priority
<blowfist>
there is one that is getting decent called box86 but it only supports x86 for now
<isd>
In the long run I think it's important, because arm boxes are just that much cheaper, and it would make owning your own Sandstorm server much more accessible
<isd>
I also think a lot of the things on that road are worth doing anyway: More robust, repeatable builds for example would help.
<isd>
Probably the next thing I need to do on that road is finish up reworking the syscall filter; I don't want to try porting it to another architecture until I've got that done.
<blowfist>
wasn't there some vulnerability in bpf lately?
<blowfist>
isd: are you writting bpf rules by hand or you're using a library?
<isd>
Not sure which you're referring to. There have definitely been vulnerabilities in the past, but the ones I know of are ways that you could exploit access to the BPF interpreter, which we do not give to apps -- ironically, we use seccomp-bpf to deny apps access to seccomp-bpf
<isd>
The ones I know of are not something an app could use.
<isd>
The existing filter that's enabled by default is built with libseccomp. I've written a replacement with hand-crafted BPF asm.
<isd>
...which you can enable in sandstorm.conf with USEEXPERIMENTALSECCOMP_FILTER=true, but it still breaks a bunch of apps so it's not ready for prime time yet.
<isd>
Once I have fixed most of the breakage I know about, I'll probably put a call out to the mailing list for folks to help testing it more widely.
<blowfist>
ideally, package maintainers would have the task of setting which syscalls they need
<isd>
Eh, making it configurable introduces more complexity that is worth it I think.
<isd>
It woulid actually seriously complicate setting up the filter, and the syscalls needed by different apps are not that different, really
<blowfist>
ah ok, I was thinking like what android has for it's packages
<blowfist>
but I guess that's pretty much what the powerbox is for
<isd>
So, we certainly do do limited access controls for Sandstorm resources more generally, with apps needing to request stuff via the powerbox.
<isd>
But the filter is just for the kernel API, stuff like open(), fork(), etc.
<isd>
It doesn't make sense to make that configurable.
<isd>
...it actually would be nice if apps could further restrict the set of available calls, so they could do nested sandboxing, but, per earlier conversation, the BPF interfaces needed to do that have had their own vulnerabilities, so we block them...
<isd>
At some point I want to supply a sandstorm API call that grains can use to spawn sub-sandboxes, but also not high priority
<blowfist>
well something that annoys me with sandstorm (not your fault really) is that when I run it in a jail I create with jailTools I actually have to use the actual superuser to run it. As it is in linux, it is not possible to have cascading user ns in a chroot :(
<isd>
Yeah, unfortunatley Linux doesn't really have good ways of supporting nested sandboxing; you elevated privileges for most/all of the possible sandboxing mechanisms, and there's no good way of attenuating them so they can still be used by something less privileged in a safe way. This is something I find generally frustrating too.
<isd>
Operating systems do not in principle have to have this problem. But Linux has this problem, and so unfortunately do most mainstream operating systems.
<blowfist>
just for the record, at first I was testing this with : unshare -r unshare -r id which worked fine as is, but it does not work inside a chroot. Fake root do get the capability of creating chroot and if they allowed it in a nested sandbox, it would have been extremely trivial to break out of the initial chroot.
<blowfist>
took me some time to figure that out too, the docs were not that explicit
<blowfist>
isd: there are that much x86_64 specific code in the platform?
<isd>
Just the syscall filter, really -- those are inherently architecture specific.
<blowfist>
right and that's the advantage of using libseccomp
<isd>
Even when you're using libseccomp -- iirc somebody tried to copy our filter and use it on arm and found out later it didn't actually work (I think becasue the socket syscall works differently? Can't remember) and had to issue a CVE.
<isd>
So it'll compile, but that doesn't mean it will work
<blowfist>
right, pretty much all the syscalls are different
<isd>
Other than that there shouldn't be huge differences, though there's always unknown unknowns wrt portability issues in our own code and in dependencies. Stuff would get shaken out in testing & trying to get it to build.
<isd>
The real challenge is figuring out how packagaing works in a multiarch world. Which I'm sure is solvable, but it will take some research & design work.
<blowfist>
(argh, I meant : pretty much all architectures have their own specific syscalls for doing things)
<blowfist>
sandstorm is indeed tricky to compile on any other distro than ubuntu
<blowfist>
and risc-v is coming too ;)
<blowfist>
isd: are you sure packaging would be that much of an issue? They would just need to be a distinct package for each supported architecture
<blowfist>
they do include everything they need to run after all
<isd>
I'm sure it's doable. But right now the packaging tools are not great at reproducibility, and everything assumes native builds... it's not a research problem, but it's work, not all of which is just typing.
<isd>
(Fwiw, I build Sandstorm on arch regularly. If you've had trouble building from source on some system, I'd like to know about it so we can fix the build)
<blowfist>
ok I'll keep that in mind
<blowfist>
I wonder how far I could get if I tried to compile it on aarch64
<xet7>
BTW, if kentonv needs ops on Librera.Chat #sandstorm, it's possible for him to ask at #libera so support will fix things. There could be some trolls on some channels that have been there first.
<xet7>
Anyway, most users are still at Freenode. Not Libera.Chat.
<isd>
dustyweb nabbed it for us, so we're good.
<xet7>
Ok great ! :)
<JacobWeisz[m]>
We still need to contact Libera chat to officially secure it with them, but ideally probably Ian and Kenton should both have registered nicks there first, so we can put a few of us on the contact list for it.
<blowfist>
isd: so you would like me to add the remaining variables to the overridables? BUILD, PARALLEL, LIBS and EKAM ?
<blowfist>
isd: btw compilation on aarch64 failed exactly where you predicted : at the bpf part
<isd>
blowfist: yeah, if you would.
<isd>
Re: build failure, can't say I'm surprised. I think we have an issue tracking arm support, would be good to record this for posterity.
<blowfist>
isd: alright, I updated my pull request
<dustyweb>
yeah, I nabbed it so that trolls would not and have already offered to hand it over :)