I would like to run a webserver that can serve files and execute arbitrary code. However, I want the public to have read-only access to everything on that machine, allowing them to be confident that they know exactly how any request to that server will be handled. (With the exception of a few specific files that contain passwords, which obviously need to remain private to anyone who does not have that password.) Is there a cheap and easy way to do this?
1,000🏅 Top traders
| # | Trader | Total profit |
|---|---|---|
| 1 | Ṁ24 | |
| 2 | Ṁ12 | |
| 3 | Ṁ3 | |
| 4 | Ṁ3 | |
| 5 | Ṁ3 |
This is basically what https://glitch.com/ does, if you are happy to use Node as your backend. Projects are publicly visible/clonable by default, with an env mechanism for secrets. It's very easy (unless you find Node unacceptable/difficult) and very cheap (unless the free tier doesn't meet your requirements; then I don't know whether you consider $10/mo or $96/year to be cheap).
@jcb Node is fine, that's what I was going to use anyway. Don't really want to pay anything for it, it's a tiny project that IDK if anyone will even use.
@jcb If you deploy to your server, it's game over, and it can not be trusted. A hosting service that allows making the source code available would be the perfect solution. Just make sure not to log the api key in the requests. Alternatives to consider: repl.it and https://www.val.town/
I think if you open source the code and fully automate the deployment process, that'll take you 90% there.
The remaining 10% will likely require a second person on your team. A lot of security techniques (like two-party authorization) depend on having another person watch what you're doing.
Note at serving a read-only view to the live server doesn't prove much, because you can always fake the view.
I think if you open source the code and fully automate the deployment process, that'll take you 90% there.
I don't see how this would help at all. I could always log into the server directly and fiddle with the files, independent from whatever Github integration is going on.
Note at serving a read-only view to the live server doesn't prove much, because you can always fake the view.
How would one fake sshing into a VPS account at the relevant domain name that has read-only access to the entire machine?
@IsaacKing Once you have automatic deployment in place, you're one button click away from locking yourself out altogether. (This is ~ the end goal of a Google-style SRE playbook.)
Can you elaborate on that SSH concept? I suspect that any level of access that gives people enough confidence will also let them break it.
@tfae Create a public user account on the machine, publish the password. Give it read-only access to all files except ones containing the password to the root account. I'm not sure what other details you're looking for, can you elaborate?
@IsaacKing but that ssh could be in a fake machine! While secretly the real machine has an extra `evil_thing():`
I admit that I'm uncertain what level of assurance you're wanting.
Read only ssh sounds okay. It is roughly equivalent to just having a /src/ page which sends the file content back, but is harder to fake so provides a bit more evidence. But uncertain about how much attack surface that has.
The glitch suggestion has the same issue, but it raises the cost of faking it far higher - since you would need to get around glitch's setup.
@Aleph I think it would be quite hard to pull such a trick with glitch (or a similar service), at least if the site is hosted directly via project URL. (I'm not sure how custom domains work; with that I could imagine it might be possible to claim that your site is one project when actually it's another.) But if users access the glitch project directly by id, I think either glitch would have to be in on the deception or you'd have to hack in and corrupt their infrastructure, which I'm guessing are outside the threat model here
@Aleph Oh I guess you're right; i could set https requests to the url to redirect to one place and ssh requests to redirect to another.