I understand that the notebook server is in the process of being redesigned. I have one idea that would make notebook server security easier to explain to sysadmins:
* Make a notebook server virtual machine (I guess "appliance") where the notebook users have a 1-1 correspondence with the Unix User IDs. * Make sure that the "worker process" (i.e., the sage instance that actually does the computations related to a worksheet) is run under the corresponding UID. ADVANTAGES: * All activity that a user can drive from the notebook is "accountable": If someone is filling the filesystem of the VM, at least one can see who it is from the file ownership. Same thing for runaway processes. * The ability of users to meddle with eachother's files and processes is automatically limited by the Unix security model. * In order to explain the security features of the notebook to a sysadmin, you can refer to the Unix security model. That should make it much easier to get them aboard. (usually, accountability is the thing they (should) care more about than limiting functionality). DISADVANTAGES: * For "open" notebooks such as "sagemath.org" this is probably not an option, because the number of (one time) users is much too big. I am more thinking about sage deployment in a classroom, with a fairly well- defined set of users (at a university, the students probably already HAVE a UID somewhere central) * Worksheet sharing is going to be *much* harder * NBUser account creation looks like a much heavier operation, although see below. IMPLEMENTATION: I can think of two possible options * Have two SUID programs that can be run by the notebook server (but not by workers!): create_user : set up the basic directory structure with the right ownership to start sage worker processes in. Additionally, this script could put an entry in /etc/passwd so that the system knows how to map this UID to a string. start_worker : runs a sage worker with a given UID, properly hooked up (via pipes?) to the notebook server so that it can receive orders and report back. * Set up the appropriate users on the VM and use passphraseless SSH keys to connect to these accounts, and give the public keys for these to the notebook server (this is already an option now. The new thing would be that the NBUser has a 1-1 mapping to which user is SSHed into). If a VM were available with these options (possibly with a pluggable authentication module which makes it possible to hook it into for instance a Jasig ( http://www.jasig.org/cas ) central authentication server), it would be a lot easier to get it installed on some general hardware, because students who (mis)use it could still be held accountable (unless they manage to break the server process and make it do their bidding), unless there is a proper unix breach and may help deployment. Perhaps it is easy in the redesign to keep this implementation an option, or perhaps there are other ideas that allow a reasonable amount of accountability. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
