Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I think you're confusing two things. Your Python program is not an executable in the sense that <code>libsandbox</code> is talking about. The executable is the Python interpreter.</p> <p>So, you cannot sandbox a Python script with <code>libsandbox</code>.</p> <p>You <em>can</em>, however, sandbox the Python interpreter. You do this the same way you sandbox any other executable. Either:</p> <ul> <li>Create a static build of the Python interpreter (with any C extension modules you need compiled in), and run that in the sandbox. This is not easy, but it's doable, and there's information in the Python source tree and elsewhere that may help.</li> <li>Use a more lenient sandbox that allows the standard interpreter to do everything it needs (which may including dynamically loading extension modules, depending on whether you need that) but no more. </li> </ul> <p>Either way, you will need some trial and error to figure out what you can and can't disallow, and how to map different bits of Python code to syscalls, and so on. And there will be some things that you just can't prevent your script from doing, because the same syscall you don't want Python code to execute is necessary for the interpreter itself.</p> <p>Effectively the same thing is true with Java. The JVM is the executable, not your program. And you really can't statically link the JVM, so you only have the second option.</p> <p>Unless, of course, you're using <code>gcj</code> to compile your Java code to native code instead of JVM code. In that case, you're actually using the same backend as with <code>gcc</code> and <code>g++</code>, and you just use <code>--static</code> to make sure <code>libgcj</code> and everything else gets statically linked. You may still run into problems, because <code>libgcj</code> is doing a lot more under the covers than <code>libc</code>… but the concept is the same as with C code.</p> <p>(The JVM itself has its own access model, and you could presumably build something using reflection in the classloader to sandbox Java programs at the level of the Java API instead of the linux syscall API. I don't know if such a thing already exists.)</p> <hr> <blockquote> <p>Whenever I tried to compile the program(Which i want to run in a sandbox) without "--static" , the sandbox didn't work.So, again --static is quite pivotal,, that is beyond my knowledge.</p> </blockquote> <p>Most likely, your actual code doesn't open any files, so you're using the default sandbox settings that forbid opening files. But if you dynamically link your program, it has to open the <code>.so</code> files to link against them—which doesn't work, because your sandbox is configured to forbid it.</p> <p>If you statically link the same program, the problem goes away, because it no longer needs to open any <code>.so</code>s to run. That, in a nutshell, is the point of static linking for sandboxing. You even explained this in a comment to your question, so I can't imagine how you could not understand it, unless you don't even understand why you might want to forbid <code>SYS_open</code> and what it means to do so.</p> <blockquote> <p>(a)For java and python, will the sandbox work if i compile w/o "--static"</p> </blockquote> <p>Yes, the sandbox will work just fine. Which means, if you're using the default configuration, it will forbid you from opening files. Which means your Java or Python program will fail, because the VM/interpreter has to open (among other things) your program to run it.</p> <p>Even linking the interpreter or the JVM statically wouldn't help that. You'd have to get the actual bytecode for your program statically linked into the executable. Not impossible, but probably well beyond anything you want to even contemplate at this point.</p> <p>The right thing to do is figure out exactly what syscalls you're trying to forbid, and why, and configure the sandbox appropriately. The default configuration will not work for you.</p> <blockquote> <p>(b)There is a sandbox called pysandbox by the same developer openjudge.net/~liuyu/Project/LibSandbox</p> </blockquote> <p><code>pysandbox</code> is just an easier way to configure and start a sandbox. You don't use it from inside your sandboxed code. (There is a <em>different</em> <a href="https://github.com/haypo/pysandbox#readme" rel="nofollow"><code>pysandbox</code></a> by another developer that sandboxes your code at the Python level. That may be useful to you, but it's not the same thing as a syscall sandbox.)</p> <hr> <p>At this point, I'm not sure you even know what you're trying to do. Why do you want to sandbox your code in the first place? Do you know what kinds of access your code needs in order to do what it needs to do? If you know what you're trying to do, are you sure a syscall-level sandbox is the right level to enforce it at, as opposed to something like <a href="http://pypi.python.org/pypi/RestrictedPython" rel="nofollow"><code>RestrictedPython</code></a>? Without knowing your actual use case, I can't even guess at the answers to these questions. But if you don't have immediate answers to all of them, you're not going to accomplish anything useful.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload