Feature #12105: Adjust chrooted browsers to overlayfs

Feature #12105

Adjust chrooted browsers to overlayfs

Added by intrigeri 2017-01-02 09:36:51 . Updated 2020-01-28 09:06:17 .

Status:

Resolved

Priority:

Normal

Assignee:

Category:

Target version:

2019

Start date:

2017-01-02

Due date:

% Done:

100%

Feature Branch:

feature/8415-overlayfs+force-all-tests

Type of work:

Code

Blueprint:

Starter:

Affected tool:

Unsafe Browser

Deliverable for:

Description

Their setup script currently relies on aufs.

Subtasks

Related issues

Blocks Tails - Feature #16209: Core work: Foundations Team

Confirmed

History

#1 Updated by Anonymous 2018-01-16 13:45:14

Assignee set to anonym

The parent ticket seems to be part of our roadmap, so assigning this ticket to the person responsible for the parent ticket. I’ll let you verify if this is correct or if somebody else is responsible for this, or nobody.

#2 Updated by intrigeri 2018-07-09 08:13:30

It may actually be simpler to get rid of unionfs entirely here:

configure_chroot_browser_profile: generate the chroot’ed browser profile in a new tmpfs outside of the chroot
set_chroot_browser_name, delete_chroot_browser_searchplugins:
1. copy the langpacks from $TBB_EXT to a new tmpfs outside of the chroot and modify them there
2. copy $TBB_INSTALL/browser/omni.ja from $TBB_EXT to a new tmpfs outside of the chroot and modify it there
set up the chroot:
1. bind-mount read-only the host system’s / to $chroot; compared to what we do now, that means we get all the changes that were made there since booting, as opposed to having a pristine stack of SquashFS
2. to hide sensitive data in the chroot, mount brand new (and empty) tmpfs’es on $chroot/home/amnesia; that’s the ugly part (for those wondering, no need to do the same in $chroot/lib/live/mount/persistence as long as we bind-mount / as opposed to rbind it)
3. bind-mount the profile tmpfs read-write to the right place inside the chroot
4. bind-mount the modified $TBB_EXT tmpfs read-only to $chroot/$TBB_EXT
5. bind-mount the modified $TBB_INSTALL/browser/omni.ja read-only to $chroot/$TBB_INSTALL/browser/omni.ja

Advantages:

It becomes very clear what is read-write inside the chroot (the profile directory and nothing else; or perhaps the full /home/clearnet if needed); everything else is read-only.
We can keep the modified extensions and omni.ja and reuse them accross Unsafe Browser sessions. The profile (or /home/clearnet) directory is another matter, having a clean one on every start is probably a good idea.
This allows us to use bwrap or systemd-nspawn, which simplifies setting up the chroot… and provide stricter confinement.

Downsides: