You can accept them on internal networks, just have a file size limit and don’t extract them locally, but send to some cloud service for handling. You could even have it work with email attachments if you want.
Basically:
- Put file somewhere
- Spin up runner
- Upload and execute code
- Spin down runner either upon success or after a time limit
- Send result to the student (if it to took too long, that’s a fail too)
planish@sh.itjust.works 3 weeks ago
I mean if you put up an Internet-facing unauthenticated file acceptor it will quickly become stuffed with all sorts of garbage and aspiring malware. You definitely don’t want to hook that up to an untar and exec loop, even with some notion of sandboxing. It will just start mining Bitcoins or sending spam or something.
But if it is built properly, with only authorized users being able to upload stuff, and a basic understanding of not dropping stuff where the web server will happily execute every PHP web shell someone sticks in the slot, and the leverage to threaten people into not uploading pictures of their own or others’ butts or Iron Man (2009), I don’t see why all but the file-uploading professionals should immediately give up.
lucullus@discuss.tchncs.de 1 week ago
Security noob here. Would it be sufficient (in addition to only local authorized access) to directly put the file in an unprivileged container, watching its log output? And of course limiting resource use and execution time of the container (don’t know if common container tools like docker or podman have a way to limit resources out of the box)
So lets say a simple interface for the file upload behind an authentication service, based on lets say python cgi, ramping up an unprivileged nonroot docker container, killing the container after a fixed time (a few seconds).
planish@sh.itjust.works 1 week ago
Probably.