search

subgraph / oz

OZ: a sandboxing system targeting everyday workstation applications
https://subgraph.com/sgos/
Other
431 stars 57 forks source link

Make sandboxing file managers viable #105

Open matthewruffell opened 7 years ago

matthewruffell commented 7 years ago

After the incident where it became apparrant that file managers are a prime target for being sandboxed with nasty consequences if they aren't, I had a think about how it would effect the user experience and what oz needs to make file managers like nautilus work.

User experience

So far neither Subgraph Os or Dapper Linux have not sandboxed nautilus because we are worried about changing the user experience when it comes to managing user's files. These are the features that MUST work in order to ship a sandboxed file manager

- Making new files (usually from a ~/templates)
- Making new directories
- Copying files
- Pasting files
- Clicking a file and launching its respected application
- Mounting and accessing mass storage devices
    - USB / firewire
    - FTP / sshfs

I'm arguing that all of these features are perfectly possible, and literally all of them we get for "free" if we whitelist correct directories etc.

What oz needs to make nautilus work

Oz needs 4 main things to make nautilus work:

1) Fix a bug where ${HOME} cannot be whitelisted I tried to whitelist ${HOME}, and got the following error:

Target (/home/liveuser > /srv/oz/rootfs/home/liveuser) already exists, ignoring!

/home/${USER} is not mounted. Any directories that have been added ontop of ${USER} such as ${USER}/.config/nautilus still mount fine. I know you could limit to XDG_XXX_DIRs but I personally think that breaks the user experience too much, and users should be able to create arbitary folders in their home folder, hence whitelisting the whole of ${USER}.

2) Enable USB Sticks and external drives to be accessed.

I tried to whitelist /run/media/${USER} on Dapper Linux since this is where USB mass storage is mounted, and it appears, but the contents of the folder are owned by root, so nautilus cannot access mounted usb sticks.

3) Make sure things like FTP drives can be mounted. Should work out of the box with networking configured properly, maybe some tmpfs needs to be constructed.

and finally the biggest change,

4) Enable additional Oz sandboxes to be launched from within sandboxes.

This would enable the user to click a file, and for the file to open in a new sandbox for that specific file. I have tested that it is possible with oz launch placed inside the Exec of the .desktop file, and it does indeed trigger the cannot launch new sandbox warning, so .desktop files still do their jobs, even when inside sandboxes.

Currently, when you attempt to launch a new sandbox within an existing sandbox, you get the message:

Cannot run oz client inside of existing sandbox!

and the sandbox launch fails.

This restriction needs to be removed, but it needs to be heavily restricted. I suggest the following restrictions:

4.1 I suggest that a new boolean flag be added to Oz profiles, something like EnableSandboxes or AdditionalSandboxes, which is set to FALSE by default. When true, the oz binary is allowed to talk to oz-daemon and arrange a LAUNCH. No other oz command should be allowed. The reason to set this to false is to prevent malicious applications launching arbitary sandboxes for installed profiles. This option should only be enabled on profiles which require this, such as file managers, as their .desktop files will typically perform a sandbox creation event.

4.2 If a file is sent as an argument, such as selecting a picture file in a file manager, the file should only be available to the newly launched sandbox if it is reachable as a file that exists, that is, a file that exists on the file system / home directory tree, but not a file that exists only in an unmapped directory inside a sandbox. This prevents arbitrary files being written and sandboxes launched on these files, instead, these files must be located in a well known directory.

I think that it's pretty important that we seriously consider doing all this, as sandboxing critical apps like file managers should be a priority.

xSmurf commented 7 years ago

I'll look at this more in depth at some point (it's also a discussion we've been having internally for some time now); but a couple of notes for right now:

  1. isn't a bug per say, what you want is to pass along the "force" flag for the item

  2. /run/media/${USER} seems to be Fedora specific, Debian/SubgraphOS uses /media/${USER}, you could maybe inspire yourself from the work done for this to provide a patch to support both?

  3. Sandboxing nautilus may require the trade-off of not supporting network drives since networking seems like something that would not be wanted in the sandbox. Something to think through and discuss further.

  4. Has a number of existing tickets, however it's something that, as you mentioned, requires careful considerations. (See: subgraph-os-issues/issues/218) And definitely needs more input wrt overriding xdg-open/mine handling.

It's worth remembering that a number of things would still not work when doing this. For example it will likely not be possible to mount new devices, including encrypted disks. There's a lot of consideration that needs to go into this.