System-wide sandboxing framework - sandbox-app-launcher

Development
,
61

That is OK.

Should be elsewhere.

1 Like
62

Yes something like that.

Except for app_name where this is not possible since it is given from command line. Therefore need to be sanitized. Using a whitelist if allowed characters.

That is because these home folders might get populated with data the user might hate use for if we wipe that.

Would it make sense to add the home folder to user user?
Or some reason to be outside of /home?

1 Like
63

No.

System-wide sandboxing framework - sandbox-app-launcher - #3 by madaidan

No, all apps are meant to have their own user with their own home folder and be completely isolated from the user’s own home folder. A sandbox isn’t much good if the app can easily access all of the user’s files and other app data.

What about /usr/share/sandbox-app-launcher-appdata?

1 Like
64

We might have some issues with Qt apps and the sandbox. Qt for whatever reason decides it’s an absolutely brilliant idea to expose functions that get the MAC address by using the SIOCGIFHWADDR ioctl (why a GUI framework does this is beyond me).

This means Qt apps may inadvertently execute SIOCGIFHWADDR when trying to get other system info which will make seccomp kill the program. It doesn’t even have to be trying to get the MAC address for that ioctl to be executed.

https://code.qt.io/cgit/qt/qt.git/tree/src/network/kernel/qnetworkinterface_unix.cpp#n229

https://doc.qt.io/qt-5/qnetworkinterface.html#hardwareAddress

I discovered this when Telegram was being murdered by the sandbox and dug deeper into it.

We shouldn’t just whitelist SIOCGIFHWADDR since that’s a privacy risk. We can maybe replace SIOCGIFHWADDR with a function that returns an anonymous MAC address but I’m not sure if that’s possible.

I don’t know how widespread this is. It may be a minor issue that only a few apps are affected by.

1 Like
65

As per FHS, generated files seem to belong to /var/cache (since these can be easily re-created).

sandbox-app-launcher-appdata is a good name but /usr/share seems wrong.

See:

https://refspecs.linuxfoundation.org/

What about /home/sandbox? We’d create a user sandbox (can be unused) (to block creation of that user/home folder)?

Or /home/${app_user}_${app_name}? Or /home/${app_user}_sandbox_${app_name}? Or something similar?

Otherwise /var/lib?

1 Like
66

Did you consider that getent might cause multi line replies?

getent passwd root user nobody

root:x:0:0:root:/root:/bin/bash
user:x:1000:1000::/home/user:/bin/bash
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin

getent group root user nobody

root:x:0:
user:x:1000:

Therefore this really needs to be done earlier and not in a subshell.

This looks rather unusual. Can you implement that some other way please? Using temporary files or so?
I don’t know how file descriptors would work if some sort of trickery was done with them. And few others will know either since this is so unusual. Seems unnecessary complexity and therefore perhaps attack surface.

Another reason to get rid of the file descriptor stuff.

1 Like
67

I don’t think we should use /home. These aren’t actual user home directories but app sandboxes.

That’d be alright.

Yes, that’s the point. Only the root, nobody and sandbox users/groups are shown in the sandbox.

No, seccomp has to be done with file descriptors. There’s no other way.

FDs are commonly used with bubblewrap. e.g.

bubblewrap/demos/flatpak-run.sh at main · containers/bubblewrap · GitHub

bubblewrap/demos/bubblewrap-shell.sh at main · containers/bubblewrap · GitHub

I doubt it’s a security risk. If it was, there wouldn’t be so many options requiring FDs in bubblewrap (see bwrap --help).

1 Like
68

Ok. Please at least get rid of the subshell.

And ideally also get rid of bash -c.

Otherwise please provide the manual command that works how to invoke bwrap as a script comment or here so I can have a look. If brwap manual invocation works (which must work) then I am pretty sure it can be scripted without bash -c.

1 Like
69

It’s the same as in the script. Just copy/paste it without the bash -c part and run it in your shell.

1 Like
70
1 Like
71
1 Like
72

Some apps (such as ristretto) are dying due to a lack of D-Bus and many more (such as hexchat) are giving off errors. I think we need to figure out how to start a D-Bus session bus for the sandbox users. Maybe via some systemd stuff. I couldn’t figure out how.

1 Like
73
1 Like
74

What other apps should I add?

1 Like
75

This should work but I don’t have access to a webcam or microphone currently to test this. Can someone else test it?

1 Like
76
1 Like
77

Run apps in an IPC namespace by madaidan · Pull Request #16 · Kicksecure/sandbox-app-launcher · GitHub shouldn’t be merged yet. It breaks some apps using X11. More of a reason to switch to Wayland.

1 Like
78

/shared is not a good folder location as this breaks FHS. Thereby the package gets unfit for inclusion in most distributions. It’s a new folder that is easily forgotten during backups.

It’s a question what do we optimize for?

Principle of least astonishment (POLA) is a good one.

Follow FHS? That’s a good one too.

Optimize for usability? Not necessarily an optimization problem.

Reading FHS again chapter /home. Relevant quotes…

/home is a fairly standard concept, but it is clearly a site-specific filesystem. [6]

[6] Different people prefer to place user accounts in a variety of places. This section describes only a suggested placement for user home directories; nevertheless we recommend that all FHS-compliant distributions use this as the default location for user home directories.

On smaller systems, each user’s home directory is typically implemented as a subdirectory directly under /home , for example /home/smith , /home/torvalds , /home/operator , etc.

On large systems (especially when the /home directories are shared amongst many hosts using NFS) it is useful to subdivide user home directories. Subdivision may be accomplished by using subdirectories such as /home/staff , /home/guests , /home/students , etc.

I guess the sandbox use case is closest to “large systems” use case.

/home/sandbox seems appropriate.

  • /home/sandbox/sandbox-${app_name}

(Maybe sandbox- is superfluous. [1])

Therefore advise can stay “backup your home folder”. Meaning not /home/user but meaning backup /home.

That seems to be close to FHS and also be good for usability. Better than /var/lib/sandbox which is a lot harder to remember and backup. Contents of /home are more easily discovered than /var/lib.

Also /home/sandbox/shared or something would be good. But then we must make sure that no app can be named “shared”. [1]

Thinking for restricting user user, could a compromised user user mess with app_name and make an app that shouldn’t access another apps data?

1 Like
79

/home/sandbox is too generic so I went with /home/sandbox-app-launcher-appdata. Messing with /home/sandbox-app-launcher-appdata/shared isn’t very usable. /shared is far shorter to type and easier to remember. Shared storage is something that users will likely use often (unlike the autogenerated/home directories) so it needs to be more usable.

I don’t really see much issue with /shared. We don’t need to go all out following FHS. Even popular software like Flatpak has /app.

No. I don’t see how they could do that. app_name is only executed under the sandbox. If a user messed with app_name, they’d just create another sandbox.

80

Aren’t the quotes around $(...) enough? Wouldn’t quoting those variables cancel those quotes?

Is there any reason why using bash -e as a shebang isn’t used at all in Whonix instead of set -e?

1 Like