Here are a few fun things that anyone can do with a public Sage Notebook: 1. Use the Sage server as remote file storage. Take your pick between ftp, cvs, subversion, or even brew your own protocol.
2. Host your own web site. Remember: Apache is only a wget away! 3. Are your thesis simulations taking too long to run? Try distributing your algorithm to a cluster of Sage notebooks. 4. Build a process cluster that randomly kills Sage processes. For long-lasting effects, be sure that your processes can react to a partial discovery of their existence. 5. Deploy network crawlers. Who knows? You might even find another home for your remote file storage. 6. Access eJournals and other materials that are typically restricted outside of the campus network. My point: there really is no reason to root a Sage box because it already provides for many other opportunities. While rooting the box may allow you to get around the ulimit or quotas, these really do not pose serious problems anyway. The trick here is just to distribute your resource usage among the publicly-usable sageXX accounts. I'm doing some research into SELinux to see if there are any tricks that can be done to eliminate these issues. If possible, I would like to do the following: 1. Disallow the sageXX accounts from opening sockets in any program except Sage. This would prevent people from running open-source servers (such as subversion or apache), but it would not prevent them from writing their own servers within the Sage Notebook. 2. Disallow killing processes by any sageXX account. This essentially means limiting the interrupts that can be issued. 3. Limit the interprocess communication options to all sageXX accounts. As far as I can tell, there is no reason for any of them to be allowed to create shared memory segments, process semaphores, or message queues. Although this does not make it impossible to build process clusters, it sure makes it a lot more difficult. 4. Limit the valid address range for outgoing sockets for sageXX accounts. One could easily disallow connections to any system on the campus network by banning the campus's IP range. The sageXX accounts should only be allowed to establish connections with known mathematical databases; however, the addresses of these databases can change due to IP reassignment within ISP's. Rather than having the sageXX processes perform DNS lookups (which requires establishing connections to arbitrary addresses), you could have an external process (such as server2) periodically perform the lookups and store the results in a hosts file. These adjustments certainly do not prevent the attacks I mentioned, but they do make them quite a bit more difficult to perform. Let me know if any of these adjustments would break Sage as a whole. In the meantime, I'll continue investigating SELinux to see whether or not these proposals are feasible. -- Brian --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
