<garrison>
I've had my eye on Fedora CoreOS lately. I haven't tried it, but I think it has potential as a base OS for Sandstorm to be installed on. It is a minimal, rolling release with automatic updates, so no user intervention is ever required to keep it up to date. Right now it's an "emerging" Fedora edition, so probably not worth encouraging its use
<garrison>
until it graduates. But I think it has potential along the lines of the "Sandstorm distro" we have talked about.
<ocdtrekkie>
I am not super opinionated about Linux distros, but the biggest thing will be the ease in which we can integrate critical OS settings into the Sandstorm UI, and given our work capacity, those things don't break often.
<ocdtrekkie>
We probably should spec out what we need to manage in a Sandstorm distro, and how we want to get through initial setup.
<garrison>
ocdtrekkie: what critical settings do you have in mind that should be configurable via UI? (is there an existing list of desired settings somewhere?)
<ocdtrekkie>
Well, ideally Sandstorm users shouldn't ever have to drop out of the UI. If we were to ship a Sandstorm box (imagine Helm but with Sandstorm on it), we should expect users will not know bash at all.
<ocdtrekkie>
So the biggest thing is network settings would need to be configurable from Sandstorm (and we'd need to figure out how our own sandstorm.conf would be edited within Sandstorm).
<ocdtrekkie>
Sandstorm should then, presumably, set and manage good security practices for the OS, perhaps generating a root password and such?
<TimMc>
Chicken and egg problem right there -- how do you get to Sandstorm before the network is configured correctly?
<TimMc>
although it's fine if you can attach a keyboard and monitor
<garrison>
Helm as in the k8s package manager? (I have not used it.)
<ocdtrekkie>
Even if people want to install the Sandstorm distro on a machine they bring, the Linux installer needs to also set up and configure Sandstorm.
<isd>
Yeah, I think getting ekam to build with nix is still the next step
<garrison>
I'm somewhat skeptical of NixOS as base if the goal is to be able to configure the system through a GUI. In all my experience with NixOS, the GUIs provided for system administration are at odds with it. Do you know of any counterexample?
<ocdtrekkie>
FWIW, we want to build something extremely purpose-built with minimal exposed configuration needed to securely run the machine.
<Corbin>
Nix can be configured programmatically, which is one step better than a GUI in terms of flexibility. But I can understand the hesitation; it's a very different way of building a distro.
<ocdtrekkie>
People obviously could get into messing with it, but the goal will be to cover the use case where people do not. So mostly network configuration, any security setup we can't just pick a good default, etc.
<isd>
I think nix is more compelling for dev tooling than it is for building a sandstorm distro. I could see it being part of the process for building a distro image, but we would definitely end up hiding it from the end user for the most part (though that's going to be true of more or less anything we pick as a distro base).
<garrison>
isd: I agree
<isd>
fwiw, one of these days I want to get sandstorm's UI to only use public capnp APIs, so that in principle anything that can be done in the UI is also doable programmatically. We of course need client-side capnp for that, and then just a bunch of work to make it happen.
<isd>
(In principle, you could use DDT right now, but it's not really documented or considered stable)
<isd>
DDP? the meteor thing, can't remember what it's called.
<ocdtrekkie>
DDP
<ocdtrekkie>
Yeah, that weird thing.
<garrison>
by client-side capnp you mean in the browser? so basically a more mature pure javascript implementation?
<ocdtrekkie>
Random musing: If we want to make Sandstorm viable to use to operate businesses, we should at some point consider what businesses could be run on Sandstorm, and what apps we'd need to have to support those businesses.
<ocdtrekkie>
I was thinking in particular about MSPs after the SolarWinds and Kaseya things and stuff. It'd be nice if one could run an MSP on Sandstorm.
<ocdtrekkie>
Presumably Sandstorm would need a network monitoring tool and a help desk system to operate an MSP with it.
<xet7>
Wekan will sometime become to be help desk system, when sending email to cards starts working
<xet7>
I don't know is using websockets safe enough. Should long polling used instead?
mnutt has quit [Remote host closed the connection]
mnutt has joined #sandstorm
<isd>
Not sure what the supposed problem with websockets would be?
<Corbin>
They're just sort of loathsome in the technical details. I've implemented them once and wouldn't do it again.
<isd>
Was asking in the context of xet7's comment.
<kentonv>
woke up to a bunch of weird security disclosures made through huntr.dev, which I hadn't previously heard of. Two were outright false: That anyone can log into alpha.sandstorm.io (duh, by design), and that the Meteor WebSocket is accepted cross-origin (yes, it is authenticated by token, not by origin header).
<kentonv>
the third one was noting that someone could spam email login token requests -- across varying addresses, to avoid the per-address rate limit -- in order to incur fees from the server's mail delivery service
<kentonv>
obviously I don't consider this much of a vuln or I wouldn't be describing it here on IRC
<kentonv>
but I suppose that, indeed, if someone wanted to be obnoxious, they could do this
<ocdtrekkie>
I was curious if we'd get anything interesting or not. Was the second time this month we were asked for the disclosure address.
<kentonv>
(all three reports were from the same researcher)
<kentonv>
the guy wants me to mark the third report as "valid" which triggers huntr.dev itself paying out a bug bounty and possibly issuing a CVE. I am not sure how I feel about this.
<ocdtrekkie>
They appear to pay out for vulnerabilities confirmed by the maintainer.
<ocdtrekkie>
So that's probably a big incentive to push out vulnerabilities for projects which don't offer their own bug bounties.
<ocdtrekkie>
I am not sure "it's possible to use the email service to send email" is particularly valid, as that is it's purpose. That'd be like saying Gmail is vulnerable to send too many messages which can waste people's bandwidth.
<kentonv>
well I guess the guy's point was that we should impose a rate limit per client IP
<isd>
So what would the fix be? You could put a global rate limit in place. But that turns it into a DoS.
<kentonv>
which, like, I'd accept a PR doing that
<ocdtrekkie>
I don't think it's a security issue though.
<kentonv>
but... meh... this is the kind of thing where an attack is mildly obnoxious, not catastrophic, and it seems fine not to do anything about it unless we actually see someone try it
<isd>
Ah, yeah, I guess we could do per client. But you could spoof IPs to get around it...
<kentonv>
you can't spoof IPs unless you can MITM them in which case you can probably do a lot of evil stuff
<kentonv>
of course you could always use VPNs or ipv6 or Cloudflare Workers or whatever to get a lot more IPs
<isd>
spoof is the wrong word, yeah the latter is more what I had in mind. Haven't had tea yet.
<isd>
I don't think there's a way to allow randos on the internet to use a finite resource without risking exhausting it.
<kentonv>
TBH the best known solution here is probably to sign up for Cloudflare bot protection, heh.
<kentonv>
I suppose captchas could help too
<ocdtrekkie>
If there was a captcha that didn't feel inherently hostile to users.
<isd>
Are tehre FOSS options for captchas? I'd be okay with it depending on details (maybe as something admins could enable), but I would not be okay with just using recaptcha.
<kentonv>
I would guess that if there are FOSS options, they are probably relatively easy to bypass with automation. Really hard captchas are a difficult problem.
<kentonv>
but it could still be a speed bump
<kentonv>
like, who is really going to go out of their way to run up someone's email delivery bill anyway?
<isd>
I could see the argument for adding an option for a global cap, but mainly because afaik mailgun doesn't offer this.
<isd>
Which, really want you want is a spending cap. This seems arguably an email provider plan.
<isd>
*problem
<isd>
Not that we shouldn't necessarily fix it.
<isd>
Mailgun free tier is $0.80 per 1000 messages after the iniital 5000 per month
geex3 has joined #sandstorm
<ocdtrekkie>
I don't think compensating for other services' billing option failures is in-scope for us. Wouldn't we then have to make assumptions about billing cycles and such for such an option to be effective?