Hi, This is a good discussion. It's interesting to see, after all this time, the public notebook being attacked! (exclaimed in the most respectful, positive, excited that now this problem really has to be solved manor :)
Over the last few months I've been thinking about and working on the problems associated with running notebook processes (which is like essentially handing out shell accounts) in a safe, secure and useful way. I split the problems into orthogonal (as possible) components, and the one I worked on most recently asks 'what is the best way to run a secure python process'. There are quite a few pieces of work that exist on this problem; probably the main bottleneck in progressing is my inexperience with system administration and knowledge of how Python works. Rough work and references: http://trac.knoboo.com/wiki/Security I've made some headway in directions varying from Sage's security model as it was, but unfortunately I am too busy at the moment to make any serious progress. I plan to resume working on this in about a month. It would be great to consult and collaborate with Michael Mabshoff and any other experienced gurus of that sort -- sys admins and programmers that really understand security in the os environment. On Mon, Oct 13, 2008 at 3:31 PM, mabshoff <[EMAIL PROTECTED]> wrote: > > On Oct 13, 3:05 pm, "Timothy Clemans" <[EMAIL PROTECTED]> > wrote: > > Hi Timothy, > > > I had never heard of "fork bomb" until now. According to Wikipedia, > > it's somewhat preventable by implementing a limit of the number of > > processes per user. > > just read "man ulimit" :) > > > I like the fact that Knoboo makes it easy to run the actual Sage > > processes on a completely different machine or at least in a virtual > > machine. At some point Knoboo might have a system for dealing with > > down kernel servers where one can still access and download notebooks. > > Nope, once you fork bomb and you do not have a root shell open to the > box it is game over in the vast majority of cases. Any external access > usually requires a fork of some sort and since someone just fork > bombed the box it is a gonner. Actually, the concept Timothy is talking about is true. The framework for running notebook processes in Knoboo is very different from what Sage does to serve notebooks. Indeed, the machine running actual notebook processes (or engine processes as we call them) is considered history in this situation, however, access to the notebook data would be absolutely un-affected -- an important point -- because users *can* still view/download their notebook data as it is maintained by an entirely separate system running on a physically separated machine. Not to be nit-picky, but this is very attractive from a user perspective; it's not as catastrophic as the entire service disappearing (like what's happening now). > > > > Would the entire Sage Notebook be ran in a VMWare image or the > > individual Sage per sage unix user processes inside their own? So like > > sage0 would have a virtual machine, sage1 would have its own, etc. > > Yep, that is pretty much the way to go together with some more tweaks > to the setup. The main issue is that a skilled attacker (not likely > the person who fork bombed the box) can break out or DOS pretty much > any setup, so one has to assume that people interested in using the > Sage notebook are neither idiots or assholes. Back in the day I also > did penetration testing and in the end if you give someone a local > shell account (which is pretty much any notebook account) you have to > trust the person to some extent. Given a shell account it is only a > question of time even for someone semi-skilled to execute an exploit > found on the net before one can patch the box. I guess in the end the > people relying on the public notebook server are the screwed ones here > because even once the server is back up it will be much more locked > down. > This raises the issue of how to balance security (how tight to lock the server down) with feature/functional availability (what functionality is crippled due to imposed security constraints)... Regards, -Dorian > > Cheers, > > Michael > > <SNIP> > > > --~--~---------~--~----~------------~-------~--~----~ 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://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
