WIP: readonly www dir

[kusma]

Leaving the www_party and www_admin directories writable is just remote-code-execution bugs waiting to happen.

So I propose to harden this, by moving all files written somewhere else, with a few exceptions:

• www_admin/.oplock -> /tmp/.wuhu.oplock
• www_admin/result.xml -> /tmp/.wuhu.slide-events (should probably be in /var/data/wuhu instead)
• www_admin/activeplugins.serialize -> /var/lib/wuhu/activeplugins.serialize

According to the FHS spec, /var/lib/wuhu should be the right place to place non-user edited config, like result.xml and activeplugins.serialize. We should also update the documentation and probably the sanity-checks accordingly as well.

The one big elephant left in the room is the slides. That seems like a lot of churn to fix, and we already block any php-files from being uploaded there, and there's only a single php-script in there in the first place. So it's a bit less worrysome.

That being said, people could still use one of the many alternative extensions for PHP scripts, bypassing the security. So uggggh. At least none of these are under the www_party directories, so it was always safe to make that directory read-only, it seems. I still don't trust everyone on the organet to not try to do nasty business, as something bad like that happened due to a rogue sponsor with equipment in the organet at some Evoke.

Another motivation for keeping these directories read-only, is to synchronize them from either a read-only docker volume, or a git checkout. In both cases, it can be convenient to know they don't change behind our backs.

Thoughts? Is this something that could be interesting upstream, or should I just carry nasty downstream patches for now?

[Gargaj]

A possible halfway house solution would be to just ask for a scratch space dir on install and then put all of those files there.

[Gargaj]

I still don't trust everyone on the organet to not try to do nasty business, as something bad like that happened due to a rogue sponsor with equipment in the organet at some Evoke.

I have to trust organet, just to keep my own sanity.

[kusma]

A possible halfway house solution would be to just ask for a scratch space dir on install and then put all of those files there.

Yeah, that sounds like a reasonable alternative. I probably won't work further on these patches for now, because I believe things work well enough for my needs for now, and I need to focus on other things in the short term. I'll get back to this eventually, though.

I have to trust organet, just to keep my own sanity.

Yeah, it's probably not the best argument. I mean the better solution is probably to not allow untrusted entities onto the organet in the first place, even if they are sponsors. If they operate network equipment, they can live out in the DMZ, for instance.

However, there's other practical reasons why a writable www_orga-folder isn't great, so I think the end-goal is still worthwhile.

[chainq]

My main concern is if changes like this complicates things for other orgas, who potentially has to work on the page, then that all falls back to the one person (read: me), who is responsible for the server, babysitting every single change. Most organizers are technical people, but there's a lot of colors to that, that doesn't immediately imply everyone is very Unix-savvy. I literally had people half freak out when they were told to use an SSH key, instead of a password to login, to edit stuff. Not to mention getting PuTTY and WinSCP accept the keys that have been generated for them. Now, try to tell these people that things are at 5 different places, because security standard X. I'm exaggerating, but you probably get the issue.

So I agree what Gargaj said. We need to trust the organet, at least for that three days (or few weeks, at worst) until the server is up per year.

On the other hand, I'm all for moving temp files and lock files, and whatever other temporary stuff out of the default directories by default. I'm also all for increasing security, but then we also have to consider how to still enable organizers to do changes they need to do.

[kusma]

@chainq: I don't think these changes complicates things for anyone at all, it just makes it possible to make these directories read-only. I'm not trying to force anyone to do so.