Thomas Hruska a écrit : > David wrote: > >> >> There are too many security issues on using a full C++ implementation. >> May be using a dedicated virtual machine could a solution (even if too >> costly) >> > > Setting up a unique virtual machine in a timely manner isn't going to > happen in the near future. Unless you mean one virtual machine > everything runs under. Might be doable but you would want to refresh > the machine every hour or so. > >
Some demos on the web reload a save state every night. > I was thinking of maybe something similar to strace only designed to > provide an outer defensive sandbox. And then a custom run-time library > to compile against for inner defenses. Someone trying to bypass the > custom library would hit the outer sandbox. Obviously, this sort of > setup is better suited for a Linux environment. Could also create a new > temporary user for each program part of a very restrictive group. At > the end, results are dumped to the browser and the temporary user is > deleted. > > > strace. oh yes. But I should be diffilcult to recognize malicious use of code. But I good idea for project indeed. >>> Their system also depends on sending e-mail results >>> because problems are processed through a queue. >>> >> A basic of asynchronous call. >> In fact, the mail is quite new for the newbies. >> Before, there was only a page that display the result of your code for a >> problem, >> and sometimes, I can be difficult to know why your code didn't compile. >> The mail help to have the error message. >> >> >>> I want something that >>> puts the results in the same browser session (probably involving AJAX'ey >>> goodness). And it would also be nice to have a "virtual console" via >>> AJAX where you can type stuff into a 'cin'ed app. and have the typed >>> letters be forwarded from the browser to the app. >>> >>> This would be a great project for a student who's brain is gnawing its >>> way out in class. That is, you fully comprehend what is being taught >>> and are bored to tears and want something useful and HARD (yet extremely >>> cool) to do. This is not an easy project when you place the security of >>> the host system at top-priority and yet want to allow file I/O, sockets, >>> and other things. Blocking those things is easy. Allowing such things >>> makes security of the host hard to impossible. >>> >> This is probably why Java (and it is security system) was created ;) >> > > You run into the same problems with Java if compiled and executed on the > local host and allow file I/O, sockets, etc. > I thought more on the applet part. But yes, it came to the same for a server. > Besides, the point of this is to allow C/C++ to be compiled/run on the > host from a server. Not Java. This is c-prog after all. We are only > _slightly_ biased here. ;) > > Java ? what is Java ? :)
