On 10/16/07, TrixB4Kidz <[EMAIL PROTECTED]> wrote: > > I would suggest not to actually use unixy infrastructure to create the > > users. But that certainly involves a decent amount of coding to do > > your own user creation/permission management and so on. Trying to > > secure unix user accounts seems doomed in my opinion. > > I agree to some extent. However, Python and sh are really only > limited by the permissions of the underlying Unix user. If this user > can execute processes / open sockets / etc, then the notebook is still > at risk of becoming a unit of a larger attack. sh can be limited by > creating a small enough jail for the server-side users.
That's what I want to do. Does anybody know how to do this? I.e., if you admin a linux system, can you configure it so a certain group of users cannot open sockets? It's a straightforward question. I think Timothy Clemans may have answered it in his earlier post about iptables for users, though I haven't had time to look yet. > Is it > possible to create a white-list (or possibly black-list) of Python > bindings? This could be used to offer only a subset of the typical > Python commands. > > The problem I can see with this solution is that certain core SAGE > functions might require these "hidden" functions (ex: functions that > need to access databases). Using the bindings in the SAGE core and > then unbinding them is probably not a strong enough solution. Based > upon what I know about Python binding (which isn't much), it sounds > like it is impossible to instantiate pure private variables; hence, a > determined user could always find an object that is using the > "blocked" functionality and bind to one of its private variables. This is definitely *not* what I want to do. People can always find clever ways to get around it, and the resulting system is a pain for legit users, since many things that should work doesn't. > An alternative would be to completely eliminate the bindings from the > core and instead encapsulate the necessary functionality within > another language, such as C, C++, or Java. In this case, sockets > would still be usable by the core libraries, but they would not be > available within the shells. When you learn more about what Sage actually is under the hood, you'll see that this is not a good idea. William --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
