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: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
