[sage-devel] Re: Fun Things to do with a Sage Notebook
Just out of curiosity are you listing options like the above since you want somebody to implement them, or are you listing them because you want to implement one of them, and you want feedback before you choose the one that you want to implement? I'd be willing to implement this functionality. Let me know which authentication modules would be most useful. In the meantime, I'll start designing some abstract interfaces. --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Fun Things to do with a Sage Notebook
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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fun Things to do with a Sage Notebook
I think the public free Sage notebook should be configured so that the sageXX accounts cannot open sockets to the outside world. Period. If I knew how to configure this in 30 minutes, I would have done it already. Once we nail down a reasonably secure public sage notebook configuration, I think we should configure a vmware image wiht it, and make that available to people. Excellent. Prohibiting socket access will be easier to implement than building the compromise I proposed. 2. Disallow killing processes by any sageXX account. This essentially means limiting the interrupts that can be issued. I don't like this, since the net result will be lots and lots and lots of zombie processes. Also, people killing other people's processes is just slightly annoying vandalism and nothing else. Also, I think there should be a 1-1 mapping between sageXX accounts and notebook user accounts. Whatever vmware image we configure, it'll be that way. Building a 1-1 mapping between usernames and Unix accounts will indeed eliminate the need to restrict the kill command. I believe it would be hugely beneficial to build an abstraction layer between the Sage user accounts and the underlying system accounts. For instance, suppose a cluster of Sage servers are deployed for use on campus. It would be useful to obtain the user's credentials from an LDAP server or some form of single sign-on service. I'm guessing people would find one or all of the following user abstraction modules useful: 1. Sage usernames, passwords, and meta-data stored in db backend. When accounts are accessed, they are temporary mapped to a system user based upon a predetermined server pool (similar to what is done now). 2. Sage usernames and passwords come from Unix backend. Extended meta- data for each user (such as Sage-related settings, etc) are stored in a db backend. 3. Sage usernames and passwords are authenticated based on LDAP information. Extended meta-data stored are stored in a db backend (note: at some point, a mapping must be made back to a Unix account. A new account could be generated based upon the LDAP information, but this is probably less than desirable for several reasons.). Alternatively, we could have the sage notebook server just kill absolutely all processes belonging to sageXX every so often. That's the price of using a free resource. True, but that seems a little unfriendly -- 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/ -~--~~~~--~~--~--~---
[sage-devel] Secure Notebook Deployment
still need to be careful about how you set file and executable access for these individual users, but as you can see this alternative already makes the server quite a bit safer. The only remaining exploit that I can think of is due to the power of the Python language. Potentially, even if you got rid of programs such as scp (for file transfer, if you recall), someone could write a simple file-transfer program using Python and sockets. Once again, a black-list might be able to address this issue, but another solution is probably necessary. Anyway, I've been typing this message long enough. I hope to hear from you soon about your thoughts on these issues. -- TrixB4Kidz P.S. You have a few hundred defunct sage processes running on your system. --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Secure Notebook Deployment
Hey again. I actually got a similar reply from William earlier today that I was going to append to this message (this post took quite some time to appear on google groups for whatever reason). The particular attack that I described is preventable, but the fact that the users have full access to a shell creates the potential for large security vulnerabilities. In particular, what about the other systems on your network? You've just given everyone access to your system behind your firewall. With this, I could easily write a script that punches a hole through your firewall and creates a pipe to one of your blocked ports. What I'm more concerned about is the fact that this model opens the rest of your network up. I mean, the attacker is behind the firewall on a computer that is part of a campus's internal network. One could build a crawler in Python that discovers the hidden network topology, port maps all of the systems, and sends the results back to their system via a raw socket or scp. So even if your server is rock-solid, the attacker has still learned about several other potential entry points into your network. Hence, the SAGE server could simply serve as a stepping stone into a larger-scale attack on the network. On Oct 16, 6:02 pm, Timothy Clemans [EMAIL PROTECTED] wrote: Hi, The public notebook servers on sage.math.washington.edu are jailed (http://sagemath.org/doc/html/inst/node10.html). Also there is a pool of 30 unix users that are used to evaluate worksheet code. That protects the main notebook system from a random user. Ulimit is also used. If I remember right William welcomes people to try to vandalize the notebook server athttps://sage.math.washington.edu:8102 --- How William runs the public notebooks from William himself: (1) have a file that starts the notebook by running a .py file: [EMAIL PROTECTED]:~/nb1$ more start_notebook cd /home/server2/nb1 sage notebook.py nohup.out (2) The actual .py file: [EMAIL PROTECTED]:~/nb1$ more notebook.py from sage.all import * server_pool=['[EMAIL PROTECTED] -p 7000'%n for n in range(1,31)] notebook(port=8103, accounts=True, address='sage.math.washington.edu', secure=True, server_pool = server_pool, ulimit='-v 200') On 10/16/07, TrixB4Kidz [EMAIL PROTECTED] wrote: Hello Professor Stein. For a final project at Case Western, I offered to setup a cluster of SAGE servers for the math department. Unfortunately, I found that the default server setup is highly insecure. I would like to collaborate with you and find a way to modify the notebook deployment to eliminate some basic (yet severe) security issues. Since I'm new to SAGE (and Python, for that matter), I decided that the easiest way to determine how to safely deploy a server would be to login to a public SAGE server and reverse-engineer its deployment based on my queries. Coincidentally, I stumbled upon your server (don't worry -- I did not execute any malicious commands.) and discovered several risks. Using the os module in Python, you can find the following: 1. All of the processes running on the server, as well as the parameters used to execute them. 2. The username, uid, groups, gid, etc of the current process. 3. The permissions of large portions of the file system. 4. The operating system the server is deployed on. 5. All of the users on the system. 6. The programs available to the users 7. Services running on the computer 8. Devices attached to the computer (I'm guessing this is a virtualized server, though...) These are just the things I can think of off the top of my head. This is more than enough information for a hacker to bring down the server. Here are just a few potential attacks I can think of: 1. scp appears to be among the available programs in what I'm guessing was an instance of the virtualized server image. Even if gcc was not available on the server side (it appears that it is), anyone could compile an executable on their own system and transfer it to the server via scp. 2. Delete any file owned by the server uid. Based on something I read on your forum, it appears that you used to be able to delete the SAGE server itself (this was the first exploit I checked for). 3. Kill processes owned by the server uid. This means you could: - Kill the server - Create a python script that ruins system resources by (1) creating random processes, and (2) killing these with signal 9. Signal 9 does not properly return resources to the OS, so looping this for a few minutes will just eat the system. 4. By combining (2) and (3), you can actually bring down the server in such a way that it will delete all of the user accounts (I tested this on my own server). Just do the following: import os; os.system(rm -Rf ~/.sage/*); # Destroy the contents of my .sage folder os.system(rm -Rf
[sage-devel] Re: Secure Notebook Deployment
I would suggest not to actually use unixy infrastructure to create the users. But that certainly involves a decent amount of coding to do your own user creation/permission management and so on. Trying to secure unix user accounts seems doomed in my opinion. I agree to some extent. However, Python and sh are really only limited by the permissions of the underlying Unix user. If this user can execute processes / open sockets / etc, then the notebook is still at risk of becoming a unit of a larger attack. sh can be limited by creating a small enough jail for the server-side users. Is it possible to create a white-list (or possibly black-list) of Python bindings? This could be used to offer only a subset of the typical Python commands. The problem I can see with this solution is that certain core SAGE functions might require these hidden functions (ex: functions that need to access databases). Using the bindings in the SAGE core and then unbinding them is probably not a strong enough solution. Based upon what I know about Python binding (which isn't much), it sounds like it is impossible to instantiate pure private variables; hence, a determined user could always find an object that is using the blocked functionality and bind to one of its private variables. An alternative would be to completely eliminate the bindings from the core and instead encapsulate the necessary functionality within another language, such as C, C++, or Java. In this case, sockets would still be usable by the core libraries, but they would not be available within the shells. -- TrixB4Kidz --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
