| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Previously executor_for_platform() would select linux-user-chroot
if availble. New behaviour is to look for bubblewrap first, then
linux-user-chroot, else falling back to chroot. To support this, a
generic 'get_program()' function was added to both bubblewrap.py
and linux_user_chroot.py for interfacing.
|
|
|
|
|
| |
Adds in support for the bubblewrap sandbox. Comes with a logger that
logs both to stdout (WARN or higher) and to a log file (everything)
|
|
|
|
| |
Also fix a small error detected by the new tests.
|
|
|
|
| |
This module is not included in Python 3.
|
|
|
|
|
|
| |
Change some tests to pass if they are run as non-root. The
linux-user-chroot tool seems to require that the absolute location of
the binary to execute in the sandbox is given if called as non-root.
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Fix missing source argument in the 'mount' command.
- Add missing datapath assigment to ensure that file is created in
the expected location.
- Remove unnecessary extra_mounts that were causing the test files
in /data to not be accessible inside the sandbox as that directory
was being overlapped with a mount bind.
Also, mention that the C library static libraries are required to be
installed for running the tests.
|
| |
|
|\
| |
| | |
Correcting a broken test
|
|/
|
|
|
|
|
|
| |
FILE_OR_DIRECTORY_EXISTS_TEST_PROGRAM previously fetched args[0]
instead of args[1]. Program now checks the correct file when
inside of the sandbox.
Added in a simple .gitignore
|
| |
|
|\
| |
| | |
Fixed a minor bug where root logger is used instead of a named 'sandb…
|
|/
|
|
| |
If the root logger is used instead of a named 'sandboxlib' logger. This causes potential issues for 3rd party tools using this library
|
|\
| |
| | |
Issue 19 and 17: Awful hack to ensure string-escape is loaded
|
|/
|
|
|
|
|
| |
This hack ensures that when propagating an exception back from
the child process in a chroot, the required string-escape python
module is already in memory and no attempt to lazy load it in the
chroot is made.
|
|\
| |
| | |
Propagate child process traceback from chroot process.
|
|/
|
|
|
|
|
| |
Without propagating the traceback for the child, issues
such as the following become near impossible to diagnose:
https://github.com/devcurmudgeon/ybd/issues/224
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
It looks like a pretty useful sandboxing tool, with more momentum
than linux-user-chroot.
|
|\
| |
| | |
Mount more flexibility
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The mount operation is overloaded to also remount to change flags.
This does not result in a new mount,
so unmounting it is the wrong thing to do in this case.
For now, we assume that we're modifying a mount we created earlier,
so we can just avoid unmounting when we remount,
rather than having to determine how to reverse the changing of flags.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
You can't create a bind-mount as read-only,
you can only bind-mount then remount it as read-only.
So a sandboxlib user might opt to say it wants to bind something in,
then make it read-only, as two separate extra mounts.
We can't do this directly with linux-user-chroot,
as we are restricted to bind-mounts and making a subtree read-only,
but making a subtree read-only is close enough.
|
|/
|
|
|
|
| |
It's more natural to not pass -t when bind-mounting,
to not pass -o when no options are required,
and to not pass the source path when remounting.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This fixes a crash if the command fails, because we would try to decode
'err' but it would be None because output was not being captured.
|
|
|
|
|
|
| |
I thought that a typeerror was causing a crash in YBD, but realised
it was something else. This commit should still be an improvement,
though.
|
|
|
|
|
|
|
| |
This fixes https://github.com/CodethinkLabs/sandboxlib/issues/6
where passing a relative path for 'cwd' caused an error. I had assumed
that os.chroot() reset the current working directory itself, since
the `chroot` program does, but apparently not.
|
|
|
|
| |
This fixes https://github.com/CodethinkLabs/sandboxlib/issues/3
|
|
|
|
|
| |
This should have no effect on behaviour, but makes things slightly more
predictable.
|
|
|
|
| |
The `unshare` and `mount` commands are no longer needed.
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Also, remove a comment that I think is superfluous. Hopefully it's
still clear that the chroot backend should work on any POSIX OS.
|
| |
| |
| |
| |
| | |
It would always pick 'chroot' even when linux-user-chroot was available
because I'm dumb.
|
| |
| |
| |
| |
| |
| | |
The old name might be mistaken for a verb, i.e. "sandbox this backend"
or some such thing. Hopefully the new name makes it clearer that it
returns an execution backend.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|