[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] Re: Fun Things to do with a Sage Notebook
On 10/28/07, TrixB4Kidz [EMAIL PROTECTED] wrote: 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. Excellent. Let me know which authentication modules would be most useful. How about if you decide? I think you know more about authentication modules, etc., than I do. In the meantime, I'll start designing some abstract interfaces. Excellent. Feel free to post a SEP -- Sage Enhancement Proposal. William --~--~-~--~~~---~--~~ 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 sage server should just have some specific number of limited permission sagexxx accounts, e.g., 1000 of them, and then as new users are created map them to one of those accounts. There will be a hard limit on the total number of users, of course. I'm basically envisioning a pre-made chroot and a pre-made vmware image, each which has those 1000 (or 1) user accounts pre-created. That's no better than having a server pool. If a bot makes as many web accounts as you have user accounts, then they can kill just about any other worksheet process, with pretty high probability -- same problem as having a pool; it just raises the bar a little bit. --~--~-~--~~~---~--~~ 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
On 10/28/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I think the sage server should just have some specific number of limited permission sagexxx accounts, e.g., 1000 of them, and then as new users are created map them to one of those accounts. There will be a hard limit on the total number of users, of course. I'm basically envisioning a pre-made chroot and a pre-made vmware image, each which has those 1000 (or 1) user accounts pre-created. That's no better than having a server pool. Yes it is. If a bot makes as many web accounts as you have So make it so bots can't make accounts. That's a very very standard thing to implement these days. user accounts, then they can kill just about any other worksheet process, with pretty high probability -- same problem as having a pool; it just raises the bar a little bit. You are totally wrong. A bot with 1000 user accounts has no greater chance to kill another worksheet process, etc. with high probability than a bot with 1 user account. I don't understand what you're thinking. -- William --~--~-~--~~~---~--~~ 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
You are totally wrong. A bot with 1000 user accounts has no greater chance to kill another worksheet process, etc. with high probability than a bot with 1 user account. I don't understand what you're thinking. If there are 1000 user accounts, and a bot has 1000 web accounts, then either it's got one on each account, or it can experimentally verify which of its accounts overlap. Then, it can continue adding accounts until it covers all the users. Once it is running as each user account, it can watch for processes it owns through ps. Am I mistaken in this? --~--~-~--~~~---~--~~ 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
On 10/28/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: You are totally wrong. A bot with 1000 user accounts has no greater chance to kill another worksheet process, etc. with high probability than a bot with 1 user account. I don't understand what you're thinking. If there are 1000 user accounts, and a bot has 1000 web accounts, OK, noting of course that bots won't have any accounts, since we'll just implement the standard thing to make it so bots can't create accounts. However, I'll go along with this assumption for now. then either it's got one on each account, or it can experimentally verify which of its accounts overlap. The entire assumption we're making is that there is a 1:1 corresponding between user accounts and sagexxx accounts. There is never any overlap. I think the problem is that I wasn't sufficiently clear in my statement, looking back: I think the sage server should just have some specific number of limited permission sagexxx accounts, e.g., 1000 of them, and then as new users are created map them to one of those accounts. I specifically meant that new users are maped to exactly one of those accounts *injectively*. But taken out of context this isn't clear at all -- I was arguing 2 paragraphs before that Using a server pool is unfortunately not the best design, i.e., against a server pool. SO -- FOR CLARITY -- Sage notebook users are mapped *injectively* to unix users. Then, it can continue adding accounts until it covers all the users. Once it is running as each user account, it can watch for processes it owns through ps. Am I mistaken in this? Yes, but only because we're talking about something different. William --~--~-~--~~~---~--~~ 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
On Oct 27, 8:13 pm, TrixB4Kidz [EMAIL PROTECTED] wrote: Hello Brian, 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. Well, a public notebook is like a public shell account, which we have all agreed upon that it is a bad idea. Even if you restrict the notebook to accounts you give out the problems you describe are still possible for the registered users, but that is mostly due that one has in fact a local shell accounts of one has a sage notebook account. And admins should be able to spot abuse there, that is usually what they get paid for. 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. Control over sockets is possible with SELinux. 2. Disallow killing processes by any sageXX account. This essentially means limiting the interrupts that can be issued. I am not sure if that is possible, at least the result would certainly not be in the spirit of Sage. And you would need to reinvent the wheel to do that, so that doesn't make it desirable. If you are really paranoid just set up each notebook for one user only and use different accounts for each individual sage process. That way you have isolation between users. 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. As long as one has Cython a dedicated technically advanced user can get around pretty much any security measurement you might come up with. And you don't want to limit the user to do something low level. 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. That would complicate the setup of DSage on a cluster and I am not sure what the benefits are. What are you going to do with those databases? Install a rogue elliptic curve database? 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. Great, as a first step you should create a script that relabels all files under Sage so that you can actually run Sage under SELinux. That is ticket #480 in trac. Overall I believe that you have to trust the user to some extent, but use normal diligence to spot abuse. Locking down the Sage notebook will make it harder to use, and I think that the ease of use is what is so great about the Sage notebook. -- Brian Cheers, Michael --~--~-~--~~~---~--~~ 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:
[sage-devel] Re: Fun Things to do with a Sage Notebook
On 10/27/07, mabshoff [EMAIL PROTECTED] wrote: On Oct 27, 8:13 pm, TrixB4Kidz [EMAIL PROTECTED] wrote: 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. Control over sockets is possible with SELinux. 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. 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. 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. As long as one has Cython a dedicated technically advanced user can get around pretty much any security measurement you might come up with. And you don't want to limit the user to do something low level. 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. 4. Limit the valid address range for outgoing sockets for sageXX accounts. Yep, in fact limit it to *nothing*. 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 I don't care at all about the public sage notebooks not working correctly with online databases. There are only about four of them in Sage, and them not working with the free notebook wouldn't be a problem for me. 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. That would complicate the setup of DSage on a cluster and I am not sure what the benefits are. What are you going to do with those databases? Install a rogue elliptic curve database? I think you're confused about what's being proposed. Brian isn't suggesting actually changing anything or much about Sage itself, but about the recommend practice for configuring a public notebook server. It's all unix stuff that is external to Sage. It has nothing to do with dsage. 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. Thanks. Great, as a first step you should create a script that relabels all files under Sage so that you can actually run Sage under SELinux. That is ticket #480 in trac. Yes, that would be very much appreciated as a first step. William --~--~-~--~~~---~--~~ 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
On Sat, 2007-10-27 at 17:03 -0500, William Stein wrote: 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. I think that this should be very simple with iptables, provided that the kernel has been compiled with the right options, and that the relevant options are --uid-owner and --gid-owner. Unfortunately, I don't know any more than that, though. (So what I really mean is that this might be really simple for an iptables expert, or even for someone with a little bit of iptables knowledge.) --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
