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/ -~----------~----~----~----~------~----~------~--~---
