subgraph / oz Goto Github PK

UNIX Sockets are currently broken in the connection proxy.

There's a lot of things in /etc that aren't necessary and/or shouldn't be available at all. Look into blacklisting all of that, or turning /etc into a whitelist.

Right now different profiles must be written to support Wayland mode, there should be a way to auto detect which mode is used and share a profile.

Sometimes a sandbox might experience some sort of launch failure, if the sandbox uses bridge networking the newly create veth is not always removed properly.

Sometimes Xpra handling of clipboard detects some form of a recursion and disables the clipboard for a sandbox. This should be detected automatically and the clipboard feature toggled back on transparently.

Similarly to the previous /dev/shm bug, it appears that sometimes audio does not load properly on the second launch of a sandbox.

No idea how to repro however.

There is a regression bug that seems to be hanging gnome-shell when adding files from the ozshell menu.

We should verify that files don't already exist before bind-mounting them inside the sandbox. Ex: A sandbox has all of ~/Pictures available, now a user opens an image inside that directory from the file browser, it is binded on top of the already existing file.

If a profile is installed but the program itself isn't launching said command from a CLI will still result in an "Ok Received" message. Either we need to lookup first and exit(1) if the program is missing, or we need to move to a dpkg/apt hook base installation that only installs the diversion for installed programs (or both).

Tried without torbrowser running. Tried restarting oz-daemon. Here is the section of oz log from the attempted launch: https://share.riseup.net/#z_5y8ol4kepDfkx5SUlmug

Right now theming information such as Adwaita dark theme isn't passed properly to applications in sandboxes. We need to find a way to properly detect those settings and pass them along.

When selecting a different target for a whitelist the target might end up owned by root even if the origin is owned by the user.

We should probably guess the necessary permissions from the lowest available path (ex: [/home/user]/new/target)

Default directories in the home, such as Downloads and Documents, are localized by renaming them when the user logs in. This is currently incompatible with the whitelist definitions and should be addressed by looking up the dir names from XDG in the future.

It would be really nice if the main README for oz had a comparison chart that shows the similarities and differences of oz and competitors. This would make it easier for people to understand what exactly oz is and why other products aren't sufficient.

Projects that oz could be compared against include but are not limited to: regular chroots, grsec hardened chroots, lxc, mbox, subuser, docker, systemd-nspawn and full blown virtual machines.

I thing it is because it tries to launch the sandboxed evince, and this logs into the journal:

Feb 15 11:36:18 subgraph oz-daemon[765]: 2016/02/15 11:36:18 [icedove] (stderr) Cannot run a sandbox from inside a running sandbox!

A workaround is using /usr/bin-oz/evince from within icedove.

It seems that almost all the JSON profiles are corrupted and are missing a closing }.
That is causing errors when launching an oz-setup.

$ cat gajim.json  | python -m json.tool
Expecting object: line 35 column 2 (char 812)

Or when starting oz-daemon:

2015/08/20 17:18:18 Failed to load profiles: error loading 'gajim.json': unexpected end of JSON input

I'd like to be able to make an oz profile for honeybadger ( https://github.com/david415/HoneyBadger )
so that it can be effectively sandboxed while capturing raw ethernet frames and detecting Quantum Inserts (TCP injection attacks).

Currently the recommended way to run honeybadger in Linux is to:

setcap cap_net_raw,cap_net_admin=eip honeyBadger

and then run as a non-root user... however it would be nice to have much more grainular isolation than this; this setcap command gives the program much more authority than is required for packet capture; whereas honeybadger needs read-only access to a single network interface.

What do you think?

If no profile with a bridge existed and a SIGHUP issued a new profile with a bridge is added the daemon will not create a bridge as this operation is only done on boot.

Viz demo.

This is an information leak... I guess this needs to be solved on the xpra side of things, as an option obviously.

If one issues a SIGHUP to reload profiles and one of the profiles does not parse properly, the handler becomes broken and it's impossible to reload again (and thus fix the error) and the daemon must be restarted.

It seems like your profiles are the same as subuser permissions.json files. Everything feels very similar...

http://subuser.org

It would be useful to be able to glob environment variable passing, for example to pass all "XDG_*" variables.

This code should have a careful review to ensure there is no possibility for a race condition during this sensitive operation.

HOME or XAUTHORITY can be set in xpra/client.go with the other environment variables that are set before the Xpra client is launched so that the client can locate the magic cookie.

Possible contributors/users would need to know what sort of license this is released under, eg GPLv3+ LGPLv3+, etc...

Right now seccomp policy files are hand-whitelisted in the oz profile document. This was a temporary hack for a time when there was no oz-seccomp support at all in Oz.

Ideally the seccomp policy is read from outside of the Oz sandbox filesystem entirely, as is the JSON Oz profile, which is passed to oz-init via stdin.

If a dm mapper (such as a luks device) is created a sandbox is spun, it get's "stuck" and cannot be removed, even using dmsetup --force, until the sandbox is terminate.

Setting the ignore flag on a whitelist item does nothing (prevents a sandbox from launching if the item is missing).

Right now the Xpra server and client run under the generic seccomp blacklist. A whitelist should be compiled and applied instead.

It would be good to support multiple instances for a profile with a prefix for the whitelisted data.

At the same time it would make it possible to implement disposable profiles (ie non persistent overlay).

To reproduce:

User inserts USB stick with media files
Double click to open
Oz cannot bind mount those paths as they are outside of ~

It would be good (specially for the multi-profile feature) to be able to overwrite and include profiles from within /etc/oz/cells.d.

When clicking the folder icon on the Downloads page of the Tor Browser, it opens up the Files window where the text is not displaying properly (showing up as tiny boxes--see screenshot). It does appear to be pointing to the correct location, though:

/home/user/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/Downloads

Furthermore, trying to open the file via VLC directly also does not work:

File reading failed:
VLC could not open the file "/home/user/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/Downloads/32c3-7277-en-de-Breaking_Honeypots_for_Fun_and_Profit_sd.mp4" (No such file or directory).
Your input can't be opened:
VLC is unable to open the MRL 'file:///home/user/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/Downloads/32c3-7277-en-de-Breaking_Honeypots_for_Fun_and_Profit_sd.mp4'. Check the log for details.

Somehow there are a lot of proxied connections stuck in CLOSE_WAIT, in most cases that number doesn't grow much over time and seems pretty stable but once in a while it seems like it becomes leaky and more are added over time.

Somehow those proxy connections don't seem to close properly and end up getting stuck until timeout.

It might be useful to users to be able to SIGSTOP/SIGCONT a sandbox.

Right now the only way for a user to exfiltrate files out of the sandbox is by whitelisting a directory (such as Documents or Downloads) and saving/moving the file in there. There should be a way, in the matter of the ozshell adding files, to bring files that exist only in the sandbox back on the host.

I want to use OZ on my Novena - this requires adding support for ARM. At the moment I'm unable to use it because it lacks the seccomp support for this CPU.

If a profile is installed but the program itself isn't launching said command from a CLI will still result in an "Ok Received" message. Either we need to lookup first and exit(1) if the program is missing, or we need to move to a dpkg/apt hook base installation that only installs the diversion for installed programs (or both).

I'm going through the process of installing Oz. Just a few note, it should be worth noting that it requires Go >=1.4 and an additional couple of packages.
Right now I'm running Go 1.5, and I had to go get github.com/subgraph/go-seccomp and golang.org/x/sys/unix before being able to proceed with the install.

Currently breaking build.

It should be possible to configure the log output level in the oz-daemon config to stop polluting logs with debug messages in production.

oz-daemon in journalctl logs Failed to setup filesystem: failed to copy path permissions for (/home/user/Downloads/Icedove): unable to apply ACL to file.

@xSmurf claimed it was his fault.

Right now as audio is implemented as a simple pulseaudio passthrough. This should be made more granular so that a sandbox can gain access only to the speaker but not the microphone.

Hello, your project looks great, but I have looked at your code and found this which concerns me:

// Cannot be used from golang as they can one be entered from
//  single threaded processes. See: setns(2)
//Namespace{Path: "ns/mnt", Type: syscall.CLONE_NEWNS},
//Namespace{Path: "ns/user", Type: syscall.CLONE_NEWUSER},

Am I right that you are not using user namespaces? Just because some limitation of Go language?This seems really insecure, unprivileged containers (user namespaces) seems like the only way how to make containers really secure (without it, root in container is like root on host system... at least this is what I have read about it, you can harden it with SELinux/AppArmor or other MAC, but it is still not that secure as user namespaces).

Are you planning to fix this? Or did I overlooked something?

The username is set to user and is not configurable as there is a risk it might leak. This should be mentioned in the docs.

If one still wants to change the username, it also needs to be changed in /etc/paxrat/paxrat_tbl.conf.

Installation steps worked without obvious errors.
Upon attempting to start evince, I see the following logs from the oz-daemon, at which point it hangs: (oz shell won't let me inspect the crashed container)

2015/08/25 08:50:39 [evince] Hostname set to (evince.local)
2015/08/25 08:50:39 [evince] dbus-uuid: b1a8589a47cb53ad533aeaa255dc8ecf
2015/08/25 08:50:39 [evince] xpra work dir is /home/user/.Xoz/evince
2015/08/25 08:50:39 [evince] Starting xpra server
2015/08/25 08:50:39 [evince] (xpra) E Error (seccomp): function not implemented
2015/08/25 08:50:39 [evince] Child process pid=8 exited with status 1

I've been able to run xpra directly with a seccomp policy specified.

Right now the mount/unmount commands are only exposed on the socket and used by the extension, they should be made available from the oz cli as well.

Report from IRC, attempting DCC send to yourself fails due to missing getcwd() and fallocate():

audit: type=1326 audit(1456309666.003:68): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=2196 comm="hexchat" exe="/usr/bin-oz/hexchat" sig=31 arch=c000003e syscall=79 
            compat=0 ip=0x359556f93ea code=0x0


audit: type=1326 audit(1456311752.210:71): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=3554 comm="hexchat" exe="/usr/bin-oz/hexchat" sig=31 arch=c000003e syscall=285 
           compat=0 ip=0x3b696b016bf code=0x0