[sage-devel] Re: Secure Notebook Deployment
On 10/16/07, mabshoff [EMAIL PROTECTED] wrote: On Oct 17, 1:09 am, William Stein [EMAIL PROTECTED] wrote: On 10/16/07, Timothy Clemans [EMAIL PROTECTED] wrote: You're right; that's exactly what I want to do. I want to make it so the working pool sage* users can't use the network in any way. They are users in the chroot jail, so the question is -- how can I make it so a given user can't use the internet on a unix machine, assuming said user doesn't hack the machine and become a different user? I would suggest not to actually use unixy infrastructure to create the users. Not using the unix infrastructure to manage users and permissions is reinventing the wheel. In fact, it's reinventing a very difficult wheel that -- if I reinvent it -- will certainly be easily broken. But that certainly involves a decent amount of coding to do your own user creation/permission management and so on. It's coding that (1) has nothing to do with math, so I won't do it, and (2) even if I did do it, I'm sure I would get it totally wrong in comparison to the implementation in a modern unix system. Trying to secure unix user accounts seems doomed in my opinion. I agree. Trying to secure *** (insert anything) accounts against all possible attacks is doomed. However, making *** accounts less insecure is reasonable thing to do. Using IP tables is also pointless because you have http[s] access and can bring in everything you need that way. It is just a little bit more effort. I can't comment about this, but what I need is just to block a certain group of users from having *any* ability to open *any* outside connection, including http. The worksheet processes do not have anything to do with http. http all involves the server process, which doesn't have to be firewalled in this way, since it is likely much more difficult to hack (it does *not* run arbitrary code, etc.). And yes, I know, if only I would release a SageLite that was the sage notebook without the hard-to-build Sage math library, then all kinds of unix gurus would just solve all these problems for me (since then the notebook would be popular and independently interesting beyond Sage). I really want to do that. I agree. Cool. I wish I had more time to do it. 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Secure Notebook Deployment
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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Secure Notebook Deployment
Hi, The public notebook servers on sage.math.washington.edu are jailed (http://sagemath.org/doc/html/inst/node10.html). Also there is a pool of 30 unix users that are used to evaluate worksheet code. That protects the main notebook system from a random user. Ulimit is also used. If I remember right William welcomes people to try to vandalize the notebook server at https://sage.math.washington.edu:8102 --- How William runs the public notebooks from William himself: (1) have a file that starts the notebook by running a .py file: [EMAIL PROTECTED]:~/nb1$ more start_notebook cd /home/server2/nb1 sage notebook.py nohup.out (2) The actual .py file: [EMAIL PROTECTED]:~/nb1$ more notebook.py from sage.all import * server_pool=['[EMAIL PROTECTED] -p 7000'%n for n in range(1,31)] notebook(port=8103, accounts=True, address='sage.math.washington.edu', secure=True, server_pool = server_pool, ulimit='-v 200') On 10/16/07, TrixB4Kidz [EMAIL PROTECTED] wrote: Hello Professor Stein. For a final project at Case Western, I offered to setup a cluster of SAGE servers for the math department. Unfortunately, I found that the default server setup is highly insecure. I would like to collaborate with you and find a way to modify the notebook deployment to eliminate some basic (yet severe) security issues. Since I'm new to SAGE (and Python, for that matter), I decided that the easiest way to determine how to safely deploy a server would be to login to a public SAGE server and reverse-engineer its deployment based on my queries. Coincidentally, I stumbled upon your server (don't worry -- I did not execute any malicious commands.) and discovered several risks. Using the os module in Python, you can find the following: 1. All of the processes running on the server, as well as the parameters used to execute them. 2. The username, uid, groups, gid, etc of the current process. 3. The permissions of large portions of the file system. 4. The operating system the server is deployed on. 5. All of the users on the system. 6. The programs available to the users 7. Services running on the computer 8. Devices attached to the computer (I'm guessing this is a virtualized server, though...) These are just the things I can think of off the top of my head. This is more than enough information for a hacker to bring down the server. Here are just a few potential attacks I can think of: 1. scp appears to be among the available programs in what I'm guessing was an instance of the virtualized server image. Even if gcc was not available on the server side (it appears that it is), anyone could compile an executable on their own system and transfer it to the server via scp. 2. Delete any file owned by the server uid. Based on something I read on your forum, it appears that you used to be able to delete the SAGE server itself (this was the first exploit I checked for). 3. Kill processes owned by the server uid. This means you could: - Kill the server - Create a python script that ruins system resources by (1) creating random processes, and (2) killing these with signal 9. Signal 9 does not properly return resources to the OS, so looping this for a few minutes will just eat the system. 4. By combining (2) and (3), you can actually bring down the server in such a way that it will delete all of the user accounts (I tested this on my own server). Just do the following: import os; os.system(rm -Rf ~/.sage/*); # Destroy the contents of my .sage folder os.system(rm -Rf ../sage_notebook/*) # Destroy the cached notebook information os.system(ps -A | grep python); # Returns a list of python processes. Based # upon the information found in twistd.d, you # can easily guess which instance is hosting # your server ( It's the pid just before the one # given by twistd.pd ) os.system(kill -9 XXX) # Where XXX is the pid of the aforementioned python # interpreter. kill -9 ensures that no cleanup occurs # and the notebook is not saved back to disk. Hence, I can eliminate all user accounts and bring down the server. When the server is brought back up, all of the user account information will be gone. Given the current design, I believe this exploit is unavoidable (the server must have write permissions to those folders; hence, it can delete the files). Obviously, the biggest problem here is that the user has full access to a system terminal. A simple solution could be to re-bind the os.system function to None when
[sage-devel] Re: Secure Notebook Deployment
On Oct 16, 2007, at 3:02 PM, Timothy Clemans wrote: Hi, The public notebook servers on sage.math.washington.edu are jailed (http://sagemath.org/doc/html/inst/node10.html). Also there is a pool of 30 unix users that are used to evaluate worksheet code. That protects the main notebook system from a random user. Ulimit is also used. If I remember right William welcomes people to try to vandalize the notebook server at https://sage.math.washington.edu:8102 I don't think vandalization is explicitly encouraged, however we would love to have feedback on how to make the current setup more secure. Making the python interpreter environment secure (e.g. disabling/remapping os.system) without crippling SAGE is probably an intractable problem, but running SAGE sessions with limited users with limited ulimit and permissions, and running the entire process in a jail, can serve to mitigate the problem. You are right in pointing out that the SAGE server is not completely secure, and it would be great if you could help us secure it further. - Robert --- How William runs the public notebooks from William himself: (1) have a file that starts the notebook by running a .py file: [EMAIL PROTECTED]:~/nb1$ more start_notebook cd /home/server2/nb1 sage notebook.py nohup.out (2) The actual .py file: [EMAIL PROTECTED]:~/nb1$ more notebook.py from sage.all import * server_pool=['[EMAIL PROTECTED] -p 7000'%n for n in range(1,31)] notebook(port=8103, accounts=True, address='sage.math.washington.edu', secure=True, server_pool = server_pool, ulimit='-v 200') On 10/16/07, TrixB4Kidz [EMAIL PROTECTED] wrote: Hello Professor Stein. For a final project at Case Western, I offered to setup a cluster of SAGE servers for the math department. Unfortunately, I found that the default server setup is highly insecure. I would like to collaborate with you and find a way to modify the notebook deployment to eliminate some basic (yet severe) security issues. Since I'm new to SAGE (and Python, for that matter), I decided that the easiest way to determine how to safely deploy a server would be to login to a public SAGE server and reverse-engineer its deployment based on my queries. Coincidentally, I stumbled upon your server (don't worry -- I did not execute any malicious commands.) and discovered several risks. Using the os module in Python, you can find the following: 1. All of the processes running on the server, as well as the parameters used to execute them. 2. The username, uid, groups, gid, etc of the current process. 3. The permissions of large portions of the file system. 4. The operating system the server is deployed on. 5. All of the users on the system. 6. The programs available to the users 7. Services running on the computer 8. Devices attached to the computer (I'm guessing this is a virtualized server, though...) These are just the things I can think of off the top of my head. This is more than enough information for a hacker to bring down the server. Here are just a few potential attacks I can think of: 1. scp appears to be among the available programs in what I'm guessing was an instance of the virtualized server image. Even if gcc was not available on the server side (it appears that it is), anyone could compile an executable on their own system and transfer it to the server via scp. 2. Delete any file owned by the server uid. Based on something I read on your forum, it appears that you used to be able to delete the SAGE server itself (this was the first exploit I checked for). 3. Kill processes owned by the server uid. This means you could: - Kill the server - Create a python script that ruins system resources by (1) creating random processes, and (2) killing these with signal 9. Signal 9 does not properly return resources to the OS, so looping this for a few minutes will just eat the system. 4. By combining (2) and (3), you can actually bring down the server in such a way that it will delete all of the user accounts (I tested this on my own server). Just do the following: import os; os.system(rm -Rf ~/.sage/*); # Destroy the contents of my .sage folder os.system(rm -Rf ../sage_notebook/*) # Destroy the cached notebook information os.system(ps -A | grep python); # Returns a list of python processes. Based # upon the information found in twistd.d, you # can easily guess which instance is hosting # your server ( It's the pid just before the one # given by twistd.pd ) os.system(kill -9 XXX) # Where XXX is the pid of the aforementioned python
[sage-devel] Re: Secure Notebook Deployment
On 10/16/07, Robert Bradshaw [EMAIL PROTECTED] wrote: The public notebook servers on sage.math.washington.edu are jailed (http://sagemath.org/doc/html/inst/node10.html). Also there is a pool of 30 unix users that are used to evaluate worksheet code. That protects the main notebook system from a random user. Ulimit is also used. If I remember right William welcomes people to try to vandalize the notebook server at https://sage.math.washington.edu:8102 No I don't! Basically, the situation with the public notebooks is that they will remain up as a sort of public service until somebody actually visibly vandalizes them, or uses them for nefarious purposes that are noticed and reported to me, at which time they will be taken down indefinitely. At that point I'll replace them by a closed notebook that only people I explicitly give accounts to will have access to. They have been open now for about 18 months -- it surprises me that I haven't had to switch to a closed system yet. I don't think vandalization is explicitly encouraged, however we would love to have feedback on how to make the current setup more secure. Making the python interpreter environment secure (e.g. disabling/remapping os.system) without crippling SAGE is probably an intractable problem, but running SAGE sessions with limited users with limited ulimit and permissions, and running the entire process in a jail, can serve to mitigate the problem. Which is exactly what we do. You are right in pointing out that the SAGE server is not completely secure, and it would be great if you could help us secure it further. Yes, I agree.I also agree that making the SAGE notebook server 100% secure while allowing arbitrary people to sign up for accounts with no accountability is a completely unsolvable problem. That said, ideas for making it more secure without making it impossibly hard to use, are always appreciated. 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Secure Notebook Deployment
Hey again. I actually got a similar reply from William earlier today that I was going to append to this message (this post took quite some time to appear on google groups for whatever reason). The particular attack that I described is preventable, but the fact that the users have full access to a shell creates the potential for large security vulnerabilities. In particular, what about the other systems on your network? You've just given everyone access to your system behind your firewall. With this, I could easily write a script that punches a hole through your firewall and creates a pipe to one of your blocked ports. What I'm more concerned about is the fact that this model opens the rest of your network up. I mean, the attacker is behind the firewall on a computer that is part of a campus's internal network. One could build a crawler in Python that discovers the hidden network topology, port maps all of the systems, and sends the results back to their system via a raw socket or scp. So even if your server is rock-solid, the attacker has still learned about several other potential entry points into your network. Hence, the SAGE server could simply serve as a stepping stone into a larger-scale attack on the network. On Oct 16, 6:02 pm, Timothy Clemans [EMAIL PROTECTED] wrote: Hi, The public notebook servers on sage.math.washington.edu are jailed (http://sagemath.org/doc/html/inst/node10.html). Also there is a pool of 30 unix users that are used to evaluate worksheet code. That protects the main notebook system from a random user. Ulimit is also used. If I remember right William welcomes people to try to vandalize the notebook server athttps://sage.math.washington.edu:8102 --- How William runs the public notebooks from William himself: (1) have a file that starts the notebook by running a .py file: [EMAIL PROTECTED]:~/nb1$ more start_notebook cd /home/server2/nb1 sage notebook.py nohup.out (2) The actual .py file: [EMAIL PROTECTED]:~/nb1$ more notebook.py from sage.all import * server_pool=['[EMAIL PROTECTED] -p 7000'%n for n in range(1,31)] notebook(port=8103, accounts=True, address='sage.math.washington.edu', secure=True, server_pool = server_pool, ulimit='-v 200') On 10/16/07, TrixB4Kidz [EMAIL PROTECTED] wrote: Hello Professor Stein. For a final project at Case Western, I offered to setup a cluster of SAGE servers for the math department. Unfortunately, I found that the default server setup is highly insecure. I would like to collaborate with you and find a way to modify the notebook deployment to eliminate some basic (yet severe) security issues. Since I'm new to SAGE (and Python, for that matter), I decided that the easiest way to determine how to safely deploy a server would be to login to a public SAGE server and reverse-engineer its deployment based on my queries. Coincidentally, I stumbled upon your server (don't worry -- I did not execute any malicious commands.) and discovered several risks. Using the os module in Python, you can find the following: 1. All of the processes running on the server, as well as the parameters used to execute them. 2. The username, uid, groups, gid, etc of the current process. 3. The permissions of large portions of the file system. 4. The operating system the server is deployed on. 5. All of the users on the system. 6. The programs available to the users 7. Services running on the computer 8. Devices attached to the computer (I'm guessing this is a virtualized server, though...) These are just the things I can think of off the top of my head. This is more than enough information for a hacker to bring down the server. Here are just a few potential attacks I can think of: 1. scp appears to be among the available programs in what I'm guessing was an instance of the virtualized server image. Even if gcc was not available on the server side (it appears that it is), anyone could compile an executable on their own system and transfer it to the server via scp. 2. Delete any file owned by the server uid. Based on something I read on your forum, it appears that you used to be able to delete the SAGE server itself (this was the first exploit I checked for). 3. Kill processes owned by the server uid. This means you could: - Kill the server - Create a python script that ruins system resources by (1) creating random processes, and (2) killing these with signal 9. Signal 9 does not properly return resources to the OS, so looping this for a few minutes will just eat the system. 4. By combining (2) and (3), you can actually bring down the server in such a way that it will delete all of the user accounts (I tested this on my own server). Just do the following: import os; os.system(rm -Rf ~/.sage/*); # Destroy the contents of my .sage folder os.system(rm -Rf
[sage-devel] Re: Secure Notebook Deployment
On 10/16/07, Timothy Clemans [EMAIL PROTECTED] wrote: William do you really think the notebooks can be vandalized? Yes. The only secure computer is one that is not connected to the internet and is behind a secure wall with armed guards, etc. It helps if the computer is broken too. Security for machines offering services online is just a matter of degrees. If I remember right William welcomes people to try to vandalize the notebook server at https://sage.math.washington.edu:8102 No I don't! The e-mail below is what I thinking of. touché You're right. But seriously, I didn't mean that people should try to vandalize that one forever. Thanks for forwarding my email. William -- Forwarded message -- From: William Stein [EMAIL PROTECTED] Date: Jun 27, 2007 12:39 AM Subject: [sage-devel] Re: SAGE notebook 2 To: sage-devel@googlegroups.com Hi, SUMMARY: I've made the public SAGE notebook servers nontrivial to seriously vandalize or kill... I hope. Try to crack them (especially https://sage.math.washington.edu:8102). DETAILS: For the first time in history I've finally setup a first not totally-insanely-trivial-to-vandalize server in the chroot jail on sage.math. In fact all three servers: https://sage.math.washington.edu:8100 https://sage.math.washington.edu:8101 https://sage.math.washington.edu:8102 --- please hack me. are so configured. What happens is that each user worksheet runs as a separate user from the notebook server itself. In fact, there is a rotating pool of 30 worksheet users. It should now be *extremely* difficult for a user of the notebook to kill the notebook process itself, or delete vital user data. So, for the first time ever, I invite you to please try to see if you can kill the notebook server. Let's restrict the attacks to the one on port 8102. See if you break it by running malicious commands in a worksheet. NOTE: It is, of course, trivial to denial-of-service sage.math by just running lots and lots of processes at once. Please don't do that. William On 10/16/07, William Stein [EMAIL PROTECTED] wrote: On 10/16/07, Robert Bradshaw [EMAIL PROTECTED] wrote: The public notebook servers on sage.math.washington.edu are jailed (http://sagemath.org/doc/html/inst/node10.html). Also there is a pool of 30 unix users that are used to evaluate worksheet code. That protects the main notebook system from a random user. Ulimit is also used. If I remember right William welcomes people to try to vandalize the notebook server at https://sage.math.washington.edu:8102 No I don't! Basically, the situation with the public notebooks is that they will remain up as a sort of public service until somebody actually visibly vandalizes them, or uses them for nefarious purposes that are noticed and reported to me, at which time they will be taken down indefinitely. At that point I'll replace them by a closed notebook that only people I explicitly give accounts to will have access to. They have been open now for about 18 months -- it surprises me that I haven't had to switch to a closed system yet. I don't think vandalization is explicitly encouraged, however we would love to have feedback on how to make the current setup more secure. Making the python interpreter environment secure (e.g. disabling/remapping os.system) without crippling SAGE is probably an intractable problem, but running SAGE sessions with limited users with limited ulimit and permissions, and running the entire process in a jail, can serve to mitigate the problem. Which is exactly what we do. You are right in pointing out that the SAGE server is not completely secure, and it would be great if you could help us secure it further. Yes, I agree.I also agree that making the SAGE notebook server 100% secure while allowing arbitrary people to sign up for accounts with no accountability is a completely unsolvable problem. That said, ideas for making it more secure without making it impossibly hard to use, are always appreciated. 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/ -~--~~~~--~~--~--~--- -- 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://sage.scipy.org/sage/ and
[sage-devel] Re: Secure Notebook Deployment
I don't think it is the main jails you would block since they have to receive and send data in order for the public to access them. Maybe you would block the pool of sage__ users from accessing the net using Iptables. (this might be helpful -- http://www.thescripts.com/forum/thread705507.html) Also maybe you could have a whitelist for the sloane database and the others. On 10/16/07, William Stein [EMAIL PROTECTED] wrote: On 10/16/07, TrixB4Kidz [EMAIL PROTECTED] wrote: Hey again. I actually got a similar reply from William earlier today that I was going to append to this message (this post took quite some time to appear on google groups for whatever reason). The particular attack that I described is preventable, but the fact that the users have full access to a shell creates the potential for large security vulnerabilities. In particular, what about the other systems on your network? You've just given everyone access to your system behind your firewall. With this, I could easily write a script that punches a hole through your firewall and creates a pipe to one of your blocked ports. The sage server isn't behind any firewall. The math department does have a firewall, but sage is in front of it rather than behind it. That said, there are some services accessible form the server that are only campus-accessible, e.g., library web servers. What I'm more concerned about is the fact that this model opens the rest of your network up. I mean, the attacker is behind the firewall on a computer that is part of a campus's internal network. One could build a crawler in Python that discovers the hidden network topology, port maps all of the systems, and sends the results back to their system via a raw socket or scp. So even if your server is rock-solid, the attacker has still learned about several other potential entry points into your network. Hence, the SAGE server could simply serve as a stepping stone into a larger-scale attack on the network. It would be helpful if I blocked all outgoing connection from the notebook's chroot jail. I actually have planned to do so for a while, but haven't got around to it. An number of things would be more frustrating with this model, e.g., users couldn't use any of the network-aware databases that Sage has, or pull up files in the notebook from elsewhere online. But that's perhaps not an unreasonable inconvenience for added security. Actually, how do I setup networking in the chroot jail so processes in the chroot can't create outgoing connections, but processes not in the chroot can? -- 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Secure Notebook Deployment
On 10/16/07, Timothy Clemans [EMAIL PROTECTED] wrote: I don't think it is the main jails you would block since they have to receive and send data in order for the public to access them. Maybe you would block the pool of sage__ users from accessing the net using Iptables. (this might be helpful -- http://www.thescripts.com/forum/thread705507.html) Also maybe you could have a whitelist for the sloane database and the others. You're right; that's exactly what I want to do. I want to make it so the working pool sage* users can't use the network in any way. They are users in the chroot jail, so the question is -- how can I make it so a given user can't use the internet on a unix machine, assuming said user doesn't hack the machine and become a different user? And yes, I know, if only I would release a SageLite that was the sage notebook without the hard-to-build Sage math library, then all kinds of unix gurus would just solve all these problems for me (since then the notebook would be popular and independently interesting beyond Sage). I really want to do that. 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Secure Notebook Deployment
On Oct 17, 1:09 am, William Stein [EMAIL PROTECTED] wrote: On 10/16/07, Timothy Clemans [EMAIL PROTECTED] wrote: I don't think it is the main jails you would block since they have to receive and send data in order for the public to access them. Maybe you would block the pool of sage__ users from accessing the net using Iptables. (this might be helpful -- http://www.thescripts.com/forum/thread705507.html) Also maybe you could have a whitelist for the sloane database and the others. You're right; that's exactly what I want to do. I want to make it so the working pool sage* users can't use the network in any way. They are users in the chroot jail, so the question is -- how can I make it so a given user can't use the internet on a unix machine, assuming said user doesn't hack the machine and become a different user? 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. Using IP tables is also pointless because you have http[s] access and can bring in everything you need that way. It is just a little bit more effort. And yes, I know, if only I would release a SageLite that was the sage notebook without the hard-to-build Sage math library, then all kinds of unix gurus would just solve all these problems for me (since then the notebook would be popular and independently interesting beyond Sage). I really want to do that. I agree. 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Secure Notebook Deployment
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. 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. 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. -- TrixB4Kidz --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Secure Notebook Deployment
And yes, I know, if only I would release a SageLite that was the sage notebook without the hard-to-build Sage math library, then all kinds of unix gurus would just solve all these problems for me (since then the notebook would be popular and independently interesting beyond Sage). I really want to do that. Yes please. --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
