On Tue, Oct 14, 2008 at 2:13 PM, Dorian Raymer <[EMAIL PROTECTED]> wrote: > 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).
For the record, Sage already currently supports the worksheet processes running on a separate computer via ssh, though currently that machine must have access to a common filesystem (e.g., via NFS). It so happens that sagenb.org isn't configured so the worksheet processes run on a separate machine. > > >> >> > 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> >> > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
