On Oct 6, 3:02 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> On 10/5/07, mabshoff <[EMAIL PROTECTED]> wrote:
>
>
>
> > > Actually it is an exploit classified under unauthorised data access
> > Well, I classify that as an information leak, not an exploit. I should
> > be fixed, but I am not going to do it.
>
> > I could root most boxes behind a public Sage notebook and that is what
> > I call an exploit. But the design of Sage requires a compiler and even
> > if you crippled Sage by removing the possibility to compile code
> > because you remove the compiler it takes only minor work to wget a
> > statically linked gcc installed locally via python's system command.
> > You can close that hole, too. But Sage's philosophy is about
> > collaboration and trust and as I pointed out above I wouldn't run a
> > publically available Sage notebook because I know what jerks are
> > capable of. So if you care about security don't run a public Sage
> > notebook without some additional form of authentication, because
> > securing a public notebook of Sage would turn Sage into something that
> > is no longer in the spirit of Sage development.
>
> > It might be a good idea to ulimit Sage and its child processes in one
> > way or another so we do not get pari processes that run amok like the
> > ones William did kill two days ago.
>
Hello,
> (1) This is already done. All processes are ulimited in ram usage.
good, but then you should also limit the amount of CPU time to
something reasonable. I have no opinion what reasonable is in this
context ;)
>
> (2) The public Sage notebook is not secure,
> I don't think it ever will be and I have illusions
> about it being so. I think the only reasonable way to run a public
> notebook server in the longrun is on a dedicated machine that
> gets books off of a DVD, and only uses the hard disk for storing
> worksheets and other data. At some point soon I intend to replace
> sagenb.org (which is just a chroot in sage.math.washington.edu) with
> a dedicated server.
>
> (3) A simple chmod og-rwx on a few files resolve the
> exploit that Timothy C. reported; I've add a note to
> the Sage documentation about this. Thanks Timothy!
> I do want to hear about all such exploits -- there's no
> reason to not document or fix them.
>
> (4) The chroot jail used for sagenb.org serves an additional
> purpose besides security. It also keeps the disk space usage of
> the notebook under control. Nobody can accidentally create
> a large file that messes of sage.math from the chroot.
>
> (5) If Sage becomes much more popular, the public
> Sage notebooks will disappear and be replaced
> by either advertiser-supported free versions, or subscription
> only versions. The current situation -- where they are completely
> free in every sense is not long-term sustainable if demand
> for the notebooks grows too much --e.g.,, if they get used by
> 100 people at once they will become useless. If Sage
> continues to improve and grow like it is now, this is what wil
> likely happen. Whenever "sage dot com" happens, the public
> notebooks will be something that entity will have to worry about.
>
> William
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/
-~----------~----~----~----~------~----~------~--~---
