| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal is to be useful for apps which want to be flexible about which
backend they use, taking into account that not all backends are capable
of the same thing.
My idea for degrade_config_for_capabilities() is that the app first
defines the sandboxing config they would like to use, and then passes it
through degrade_config_for_capabilities(). Any changes made are warned
about, because probably the user needs to know if certain security
features are being disabled.
This commit also adds a CAPABILITIES dict to each backend.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
First, the user should get better errors now if it is not found:
sandboxlib.ProgramNotFound: Did not find 'linux-user-chroot' in
PATH. Searched '/sbin:/bin:/usr/sbin:/usr/bin'
Second, we explicitly search for the program on each call to
run_sandbox() using the same search code used in
sandbox_module_for_platform(). This shouldn't change anything, but I
think it's better practice to search for the program ourselves than to
assume exec('linux-user-chroot') will do the right thing.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This means the linux_user_chroot backend doesn't depend on 'unshare' and
'mount' any more. This in turn means it can be used by non-root users, in
theory.
This limits what type of mounts the linux_user_chroot backend can do to
'proc', 'tmpfs' and bind mounts. Adding more types without going back to
needing 'root' for this backend will require changing linux-user-chroot
itself (or creating a separate setuid helper program).
|
| |
|
|
| |
Previously only 'none' (as a string) was allowed.
|
| |
|
|
|
|
|
|
| |
Creating missing mountpoints is done later now, so that there's less
chance of them being created if bad sandbox configuration was passed.
The previous code didn't seem work correctly, probably because of
Python os.path.join() having the annoying behaviour of deleting all
previous path components if it finds one with a preceeding '/'.
|
| |
|
|
|
|
|
|
|
| |
The idea with 'extra_env' was that all 'sandboxlib' sandboxes would have
a consistent base environment with standard PATH, etc. But that's not
really workable at all, and only PATH actually matters here anyway.
Now the caller passes in the entire environment as 'env', 'extra_env' is
gone.
|
| |
|
|
|
|
|
|
|
|
| |
I had hoped that we could provide access to a subprocess.Popen()
instance directly so users could do whatever they want with the .stdout
and .stderr pipes. However, that's not always possible (e.g. the chroot
backend can't return the Popen object it creates to the caller, because
it's in a different process).
The current approach isn't groundbreaking but it is quite simple.
|
| |
|
|
| |
This is the last bit of API needed to be usable by YBD and Morph.
|
| |
|
|
| |
This is far from complete and has probably numerous issues right now.
|
| |
|
|
| |
This required a rewrite of the 'chroot' module.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Note that *sharing* the network is a different thing to *choosing not to
isolate* the network. The former implies networking will actually work
correctly, while the latter only implies that we didn't deliberately
break it. So the default network behaviour is 'undefined'.
The different backends have different capabilities, so I added a
maximum_possible_isolation() method to return whatever is the most
isolated configuration that a backend is capable of. I called this
function maximum_security() initially, but it doesn't actually guarantee
any kind of security at all so that wasn't a good name.
|
| |
|
|
| |
Also, set it correctly when running an App Container image.
|
|
|
This library is now enough to run a very simple App Container image,
using either 'chroot' or 'linux-user-chroot'.
|
