Selfprogrammable MoinMoin
moved from deprecated page MiscProposals -- ThiloPfennig 2006-11-07 16:34:25
The first wiki (lets call it "edit wiki") contains the MoinMoin sources. The sources itself are not more dangerous than normal content.
- But changing Python code without being able to try it, is not much fun. Therefore we would need a second wiki (the "test wiki" that runs on this editable sources. This obviously is a big security problem.
Executing arbitrary code (as a user, that's not our own) is the same as having a malicious user logged into your system. This not such a unusual situation. As long as there is no local exploit this user (wiki engine) can't do much damage on the filesystem. But there are some other points:
- flooding the process table
- flooding writable filesystems (/tmp)
- using lots of CPU time, memory, I/O
- doing very nasty things over the net
- using local exploits
Please add more! Isn't that already enough? 
- better one to much than one missed...
Ok. Let's assume that the test wiki is running on its own server. Then abuse of resources will only break the test wiki itself (what can be achieved easier). And let's assume we can reboot/reset the test wiki by an action in the edit wiki. This reboot/reset would terminate all (unknown) processes, clear /tmp, ... and restart the web server.
The only problem left is the web. There are lots of nasty things one can do with a server. To protect the world the test wiki server must be kept behind a firewall that will only pass the HTTP requests to it and doesn't let anything out, but the replies.
There is one danger that cannot be banned: The wiki engine can try to break the users web browser, by exploiting the numerous weaknesses of (e.g.) Internet Exploder. So everyone viewing the test wiki must know what he is doing (should he anyway if he is surfing the web).
Perhaps it is secure enough to run the testwiki in a virtual environment like User Mode Linux or VMware and using a RAM disk as file system. The host system could monitor the CPU usage and kill the process if something goes wrong. Users could restart it by an action in the edit wiki after cleaning up the mess.
edit wiki setup
- perhaps with "format *.py as python source" patch
- Action to "reboot" the test wiki
- Action to create a new source file (must do soft link)
- generate diff agains CVS
flattend MoinMoin sources in data/text
MoinMoin source tree with (soft) links to the flattend files
- readonly NFS or Samba export of the source tree
- the test wiki as file image and UML kernel
- paket filter to protect itself from the test wiki and to forward the Http requests to the test wiki
- cron job monitoring CPU usage of the test wiki, that terminates the UML process if something is suspicious.
Open questions:
- can we use CVS or arch on the source tree wit softlinks?
how to update the RecentChanges after cvs update?
test wiki setup
UML running a ramdisk that contains:
- python
support for a net fs (NFS or Samba) to import the MoinMoin sources
or shfsmount probably better: use hostfs (I expect less overhead -- JohannesBerg)
- a web server
- dummy content testing
Open Questions:
- is UML really secure enough?
- is anyone mad enough to host something like this?