[mbq]

Why, docker-initiated chroot would prevent FF from acessing any not-FF+libs files, including which this malware steals; on Qubes it would have access to everything user-readable in the AppVM, which may include some secrets as Qubes workflow involves user-supervised copying files across VMs.

Obviously docker, as opposed to Qubes, won't stop more complex malware that exploits the kernel.

[anc84]

From all I have heard, docker is not even secure enough to let user A do things in dockerthingyA and user B in dockerthingyB. From what I was told, user A could easily break out into dockerthingyB and maybe even the host. Are you sure it really is not possible short of exploiting the kernel (or docker I guess)?

[mbq]

I don't know the details, but this is rather due to fact how docker operates -- there is a daemon that runs with root privs (which are esential to create a container) controlled by a client with a protocol that has no concept of fine-graind access lists. Consequently, user A can do anything with user B's containers because docker doesn't even have such thing as container ownership. Also docker protocol involves something which is basically opening shell as root, thus users with docker access have also a passwordless sudo. All those choices are basically ok for docker because it is designed for single-user systems like developer laptops or application servers.

Currently, for multi-user systems the only safe option for containers is sadly virtualisation or emulation; nice implementation of rootless chroot is proot, http://proot.me/