Re: Chroot Jail Not Secure for Sandboxing Python?
Paul Boddie wrote: [chroot jail solutions] I don't have the details with me now, but I'll probably upload the code in the near future and post some kind of explanation of what it does here. I've now uploaded the code to the Python Package Index: http://www.python.org/pypi/jailtools It's a bit unpolished and anyone wanting to experiment with it should look at the code to see, for example, what each of the test programs do. I do *not* claim that this is a secure solution: it's an experiment where a Python process is started with access only to a set of approved modules, whose identity becomes that of a particular user, and whose environment is that of a chroot jail, with sandboxed code only then being executed inside that environment. Anyone looking for something to deploy as a solution should look elsewhere. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Chroot Jail Not Secure for Sandboxing Python?
On 6/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Jun 25, 11:58 am, Paul Boddie [EMAIL PROTECTED] wrote: On 25 Jun, 16:48, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I followed up with my ISP. Here's the answer I got: The os.exec call prepends the chroot directory to the absolute path, but does NOT provide chroot for the child process. However, as long as the environment is maintained, which contains an LD_PRELOAD, the chroot will also be maintained. If LD_PRELOAD is removed or ignored, then the chroot is ineffective. So it appears that as long as LD_PRELOAD is set (possibly to link the process to some other libraries than is usually the case), any affected processes are effectively jailed. This doesn't really sound like a traditional chroot environment, though. Another way of saying it is that every process is responsible for providing and maintaining the chroot through the LD_PRELOAD variable. Those processes only maintain the chroot if that variable remains set. Right. The only solution that would bypass this problem altogether would be a statically linked python. (is that possible?) It would have to be statically linked to a custom-modified glibc to provide the virtual chroot environment. Some solutions depend on linking to restricted libraries, and the Wiki page you referenced probably talks about them as well. I was thinking that if I were to attempt to properly sandbox any current version of CPython, I'd start off linking it to restricted libraries which provide compatible interfaces for things like opening file handles; then I'd put various policy controls in those libraries so that you can have some control over what your programs do. Finally, you'd have to stop arbitrary (extension) module loading in order to prevent programs importing some nice modules and getting round the controls: for example, importing socket or os to get access to file handles (or to process creation which might get around the controls as suggested above). Eventually, this arrives more or less at where Brett Cannon is supposed to be right now with his sandboxed Python, perhaps by a different route and with some different outcomes. It looks the like only option available to me right now is fakechroot, which really doesn't sound like it's going to work. So I'm going to give Bett Cannon's stuff (http://sayspy.blogspot.com/2007/05/i-have- finished-securing-python.html) a try. To launch a child process in a chroot you can easily just fork and then make the chroot syscall in the child process immediately after the fork. -- Evan Klitzke [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Chroot Jail Not Secure for Sandboxing Python?
To launch a child process in a chroot you can easily just fork and then make the chroot syscall in the child process immediately after the fork. It's not so easy. On Linux, you need to have the CAP_SYS_CHROOT capability to invoke the syscall; on other systems, you may have to be root. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Chroot Jail Not Secure for Sandboxing Python?
On Jun 25, 1:43 am, Martin v. Löwis [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schrieb: This wiki page suggests using a chroot jail to sandbox Python, but wouldn't running something like this in your sandboxed Python instance still break you out of the chroot jail: os.execle ('/usr/bin/python','-c','import os; os.execlp(/bin/sh)', {}) Depending on how the chroot jail is set up, this command might not work - in the jail, /bin/sh might not exist. This was my thought too. I just figured there was something special about this command that brought one to the real Python intrepreter and then to the real /bin/sh. That's odd, my ISP seem adament that this is a way to break out. I'll just have to put in the work to test to locally I guess. So is a chroot jail not adequate for sandboxing Python? You have to define your threat model. If the threat to prevent is a malicious user getting at your data, or spreading a virus through your files, then chroot is perfectly adequate. Yeah, sounds like my threat model. Maybe prevent someone sending spam, or DOS from my server too. -Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Chroot Jail Not Secure for Sandboxing Python?
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Jun 25, 1:43 am, Martin v. Löwis [EMAIL PROTECTED] wrote: You have to define your threat model. If the threat to prevent is a malicious user getting at your data, or spreading a virus through your files, then chroot is perfectly adequate. Yeah, sounds like my threat model. Maybe prevent someone sending spam, or DOS from my server too. It all depends on how much stuff you put in your chroot! If you don't put bin/sh in the chroot then you'll stop a lot of exploits from working. If you don't allow the chrooted user write permission to the chroot then you will anyone uploading a shell or any other binaries, just leaving you with the binaries in the chroot to worry about. Nothing stops someone running os.fork() from python and spawning processes to do bad stuff. However in order to do that they would have to have compromised your .py and sent some code to exec(), or found a buffer overflow within python. It is getting increasingly unlikely but not impossible. Note that root can break out of a chroot, so your users must not be root in the chroot. Chroots provide a reasonable level of security. If you are truly paranoid about security then you want to check out selinux (as made originally by the NSA). From the selinux FAQ :- The Security-enhanced Linux kernel enforces mandatory access control policies that confine user programs and system servers to the minimum amount of privilege they require to do their jobs. When confined in this way, the ability of these user programs and system daemons to cause harm when compromised (via buffer overflows or misconfigurations, for example) is reduced or eliminated. -- Nick Craig-Wood [EMAIL PROTECTED] -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Chroot Jail Not Secure for Sandboxing Python?
On Jun 25, 1:43 am, Martin v. Löwis [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schrieb: This wiki page suggests using a chroot jail to sandbox Python, but wouldn't running something like this in your sandboxed Python instance still break you out of the chroot jail: os.execle ('/usr/bin/python','-c','import os; os.execlp(/bin/sh)', {}) Depending on how the chroot jail is set up, this command might not work - in the jail, /bin/sh might not exist. I followed up with my ISP. Here's the answer I got: The os.exec call prepends the chroot directory to the absolute path, but does NOT provide chroot for the child process. However, as long as the environment is maintained, which contains an LD_PRELOAD, the chroot will also be maintained. If LD_PRELOAD is removed or ignored, then the chroot is ineffective. Another way of saying it is that every process is responsible for providing and maintaining the chroot through the LD_PRELOAD variable. Those processes only maintain the chroot if that variable remains set. The only solution that would bypass this problem altogether would be a statically linked python. (is that possible?) It would have to be statically linked to a custom-modified glibc to provide the virtual chroot environment. -Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Chroot Jail Not Secure for Sandboxing Python?
[EMAIL PROTECTED] wrote: On Jun 25, 1:43 am, Martin v. Löwis [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schrieb: This wiki page suggests using a chroot jail to sandbox Python, but wouldn't running something like this in your sandboxed Python instance still break you out of the chroot jail: os.execle ('/usr/bin/python','-c','import os; os.execlp(/bin/sh)', {}) Depending on how the chroot jail is set up, this command might not work - in the jail, /bin/sh might not exist. I followed up with my ISP. Here's the answer I got: The os.exec call prepends the chroot directory to the absolute path, but does NOT provide chroot for the child process. However, as long as the environment is maintained, which contains an LD_PRELOAD, the chroot will also be maintained. If LD_PRELOAD is removed or ignored, then the chroot is ineffective. Another way of saying it is that every process is responsible for providing and maintaining the chroot through the LD_PRELOAD variable. Those processes only maintain the chroot if that variable remains set. The only solution that would bypass this problem altogether would be a statically linked python. (is that possible?) It would have to be statically linked to a custom-modified glibc to provide the virtual chroot environment. It seems to me that if a (potentially malicious) process needs to behave itself in order for chroot to not allow the process access to the full system, then chroot is broken. But perhaps I don't understand the intent and scale of what chroot intends to do. - Josiah -- http://mail.python.org/mailman/listinfo/python-list
Re: Chroot Jail Not Secure for Sandboxing Python?
On 2007-06-25, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Jun 25, 1:43 am, Martin v. Löwis [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schrieb: This wiki page suggests using a chroot jail to sandbox Python, but wouldn't running something like this in your sandboxed Python instance still break you out of the chroot jail: os.execle ('/usr/bin/python','-c','import os; os.execlp(/bin/sh)', {}) Depending on how the chroot jail is set up, this command might not work - in the jail, /bin/sh might not exist. I followed up with my ISP. Here's the answer I got: The os.exec call prepends the chroot directory to the absolute path, but does NOT provide chroot for the child process. However, as long as the environment is maintained, which contains an LD_PRELOAD, the chroot will also be maintained. If LD_PRELOAD is removed or ignored, then the chroot is ineffective. Another way of saying it is that every process is responsible for providing and maintaining the chroot through the LD_PRELOAD variable. Those processes only maintain the chroot if that variable remains set. None of this makes any sense to me. Once an application is running inside a chroot, there is no easy manipulation the application can do to break out. The example you gave above executes a shell that is in the chroot dir. That's not really breaking out of the sandbox, it's just accessing something inside the sandbox. if your ISP is trying to enforce chroot through an LD_PRELOAD library, they might be using 'fakechroot' which doesn't look very good to me. Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: Chroot Jail Not Secure for Sandboxing Python?
On 25 Jun, 16:48, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I followed up with my ISP. Here's the answer I got: The os.exec call prepends the chroot directory to the absolute path, but does NOT provide chroot for the child process. However, as long as the environment is maintained, which contains an LD_PRELOAD, the chroot will also be maintained. If LD_PRELOAD is removed or ignored, then the chroot is ineffective. So it appears that as long as LD_PRELOAD is set (possibly to link the process to some other libraries than is usually the case), any affected processes are effectively jailed. This doesn't really sound like a traditional chroot environment, though. Another way of saying it is that every process is responsible for providing and maintaining the chroot through the LD_PRELOAD variable. Those processes only maintain the chroot if that variable remains set. Right. The only solution that would bypass this problem altogether would be a statically linked python. (is that possible?) It would have to be statically linked to a custom-modified glibc to provide the virtual chroot environment. Some solutions depend on linking to restricted libraries, and the Wiki page you referenced probably talks about them as well. I was thinking that if I were to attempt to properly sandbox any current version of CPython, I'd start off linking it to restricted libraries which provide compatible interfaces for things like opening file handles; then I'd put various policy controls in those libraries so that you can have some control over what your programs do. Finally, you'd have to stop arbitrary (extension) module loading in order to prevent programs importing some nice modules and getting round the controls: for example, importing socket or os to get access to file handles (or to process creation which might get around the controls as suggested above). Eventually, this arrives more or less at where Brett Cannon is supposed to be right now with his sandboxed Python, perhaps by a different route and with some different outcomes. I notice that you've mailed me about a solution that I mentioned in the past, but I'll respond here in order to air the ideas in public. I looked into chroot jails and saw that some solutions exist for populating directories with enough files for things like daemons or services to be executed within the chroot environment. I also looked at ways to break out of chroot environments, and there's a fairly well- known trick involving open file handles which will do this effectively for non-root users. What I then considered was the possibility of avoiding population of a chroot filesystem by calling chroot and setuid on a minimal jailer process which then loads a jailed program after having imported a permitted set of modules. I don't have the details with me now, but I'll probably upload the code in the near future and post some kind of explanation of what it does here. I'm tempted to say that the better solution involves the restricted libraries solution mentioned above, and a nice side-effect of that could be a more modular CPython that would benefit people using the software in embedded environments: you'd have to insulate the virtual machine from even the most central modules, meaning that they could potentially be detached completely in places where memory and storage are better used on other things. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Chroot Jail Not Secure for Sandboxing Python?
[EMAIL PROTECTED] wrote: I followed up with my ISP. Here's the answer I got: The os.exec call prepends the chroot directory to the absolute path, but does NOT provide chroot for the child process. That sounds like rubbish to me. If it worked like that, chrooting servers would be virtually useless. Which OS is the ISP using? Tell him to do man 2 chroot and read it. | NAME |chroot - change root directory | | SYNOPSIS |#include unistd.h | |int chroot(const char *path); | | DESCRIPTION |chroot() changes the root directory to that specified |in path. This directory will be used for pathnames |beginning with /. The root directory is inherited by all |children of the current process. [...] Regards, Björn -- BOFH excuse #282: High altitude condensation from U.S.A.F prototype aircraft has contaminated the primary subnet mask. Turn off your computer for 9 days to avoid damaging it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Chroot Jail Not Secure for Sandboxing Python?
This was my thought too. I just figured there was something special about this command that brought one to the real Python intrepreter and then to the real /bin/sh. That's odd, my ISP seem adament that this is a way to break out. I'll just have to put in the work to test to locally I guess. No. The jail is protected by the operating system - even if a perpetrator would manage to run arbitrary native code (e.g. through running a compiler) in the jail, they *still* could not access any data outside the chroot. There are very few way of getting out of the jail. One is to manage creating a device node for, say /dev/hda, and then mounting hard disk into the jail; others are listed at http://www.unixwiz.net/techtips/chroot-practices.html In all cases, you need root privileges, so if the chrooted process does not run as root, it is safe. Be careful not to put any s-bit programs into the jail. So is a chroot jail not adequate for sandboxing Python? You have to define your threat model. If the threat to prevent is a malicious user getting at your data, or spreading a virus through your files, then chroot is perfectly adequate. Yeah, sounds like my threat model. Maybe prevent someone sending spam, or DOS from my server too. It cannot help you prevent the sending of spam or DOS: it *only* affects the local hard disk (that's why it's ch*root* - as in root directory). The jailed process can perform all networking that a similarly-privileged process outside the jail could. To prevent network access, you would need additional system features, as the ones provided by SELinux. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Chroot Jail Not Secure for Sandboxing Python?
The os.exec call prepends the chroot directory to the absolute path, but does NOT provide chroot for the child process. However, as long as the environment is maintained, which contains an LD_PRELOAD, the chroot will also be maintained. If LD_PRELOAD is removed or ignored, then the chroot is ineffective. As others have mentioned (which I just repeat for additional support): Your ISP is probably thinking of fakeroot, which is entirely unlike chroot(2), with the latter being a proper kernel mechanism, not dynamic library trickery (which would indeed be easy to break out of). Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Chroot Jail Not Secure for Sandboxing Python?
On Jun 25, 4:12 pm, Bjoern Schliessmann usenet- [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I followed up with my ISP. Here's the answer I got: The os.exec call prepends the chroot directory to the absolute path, but does NOT provide chroot for the child process. That sounds like rubbish to me. If it worked like that, chrooting servers would be virtually useless. You're right. It turns out he was referring to fakechroot. Chroot shouldn't have this problem. -Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Chroot Jail Not Secure for Sandboxing Python?
On Jun 25, 11:58 am, Paul Boddie [EMAIL PROTECTED] wrote: On 25 Jun, 16:48, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I followed up with my ISP. Here's the answer I got: The os.exec call prepends the chroot directory to the absolute path, but does NOT provide chroot for the child process. However, as long as the environment is maintained, which contains an LD_PRELOAD, the chroot will also be maintained. If LD_PRELOAD is removed or ignored, then the chroot is ineffective. So it appears that as long as LD_PRELOAD is set (possibly to link the process to some other libraries than is usually the case), any affected processes are effectively jailed. This doesn't really sound like a traditional chroot environment, though. Another way of saying it is that every process is responsible for providing and maintaining the chroot through the LD_PRELOAD variable. Those processes only maintain the chroot if that variable remains set. Right. The only solution that would bypass this problem altogether would be a statically linked python. (is that possible?) It would have to be statically linked to a custom-modified glibc to provide the virtual chroot environment. Some solutions depend on linking to restricted libraries, and the Wiki page you referenced probably talks about them as well. I was thinking that if I were to attempt to properly sandbox any current version of CPython, I'd start off linking it to restricted libraries which provide compatible interfaces for things like opening file handles; then I'd put various policy controls in those libraries so that you can have some control over what your programs do. Finally, you'd have to stop arbitrary (extension) module loading in order to prevent programs importing some nice modules and getting round the controls: for example, importing socket or os to get access to file handles (or to process creation which might get around the controls as suggested above). Eventually, this arrives more or less at where Brett Cannon is supposed to be right now with his sandboxed Python, perhaps by a different route and with some different outcomes. It looks the like only option available to me right now is fakechroot, which really doesn't sound like it's going to work. So I'm going to give Bett Cannon's stuff (http://sayspy.blogspot.com/2007/05/i-have- finished-securing-python.html) a try. I've never compiled my own Python from source before. Are there any tutorials on this? Wish me luck :-) Thanks for all the help on this question. -Greg -- http://mail.python.org/mailman/listinfo/python-list
Chroot Jail Not Secure for Sandboxing Python?
This wiki page suggests using a chroot jail to sandbox Python, but wouldn't running something like this in your sandboxed Python instance still break you out of the chroot jail: os.execle ('/usr/bin/python','-c','import os; os.execlp(/bin/sh)', {}) or maybe: del os.environ['LD_PRELOAD'] os.execl ('/usr/bin/python','-c','import os; os.execlp(/bin/sh)') My ISP suggested these as counter-examples to my request for a chroot jail. (I couldn't even get Python running in chroot to test this, nor could I run these commands locally in Python on Ubuntu, though maybe they opened sh?) So is a chroot jail not adequate for sandboxing Python? -Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Chroot Jail Not Secure for Sandboxing Python?
[EMAIL PROTECTED] schrieb: This wiki page suggests using a chroot jail to sandbox Python, but wouldn't running something like this in your sandboxed Python instance still break you out of the chroot jail: os.execle ('/usr/bin/python','-c','import os; os.execlp(/bin/sh)', {}) Depending on how the chroot jail is set up, this command might not work - in the jail, /bin/sh might not exist. or maybe: del os.environ['LD_PRELOAD'] os.execl ('/usr/bin/python','-c','import os; os.execlp(/bin/sh)') How could deleting LD_PRELOAD help? chroot is not a library trick. It's a mechanism implemented in the operating system. So is a chroot jail not adequate for sandboxing Python? You have to define your threat model. If the threat to prevent is a malicious user getting at your data, or spreading a virus through your files, then chroot is perfectly adequate. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Chroot Jail Not Secure for Sandboxing Python?
On Jun 25, 1:21 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: This wiki page suggests using a chroot jail to sandbox Python, but wouldn't running something like this in your sandboxed Python instance still break you out of the chroot jail: os.execle ('/usr/bin/python','-c','import os; os.execlp(/bin/sh)', {}) or maybe: del os.environ['LD_PRELOAD'] os.execl ('/usr/bin/python','-c','import os; os.execlp(/bin/sh)') My ISP suggested these as counter-examples to my request for a chroot jail. (I couldn't even get Python running in chroot to test this, nor could I run these commands locally in Python on Ubuntu, though maybe they opened sh?) So is a chroot jail not adequate for sandboxing Python? -Greg Edit: Google groups stripped out the URL. It's http://wiki.python.org/moin/How_can_I_run_an_untrusted_Python_script_safely_(i.e._Sandbox) (or the page titled this on the Python wiki if it strips out the url above again) How can I run an untrusted Python script safely (i.e. Sandbox) -Greg -- http://mail.python.org/mailman/listinfo/python-list