minimum size for a qube image

[Jan Hustak]

Hello,

I really like Qubes' isolation approach. I would also like to isolate
the programs I run from code they don't need. So I want to split not
just my data into separate qubes, but also the software that works with
said data.

One way to do this is to install required software under /usr/local in
each qube. That has the important drawback of ignoring the qube's
package manager and the consistent updates it provides.

Another option is to build my qubes as StandaloneVMs copied from a
minimalist template. The qubes have to be updated one by one but at
least it's still done using the package manager.

So I created a Debian template trimmed to about 2.5 GB. I identified my
task domains - there were about 10 - and planned to cut a 4GB qube for
each. This would eat up 40 GB from my 500 GB drive which I can live with.

However, The VM Manager insists on at least 10 GB for each qube. Giving
up 100 GB with 75 GB empty (i.e. 15 % of total disk space) is steep. So
my question is: how can I create smaller images for my qubes?

I'm also open to discussing the basic concept: is it worth trying to
keep, for example, Firefox and GIMP in separate qubes, or should I just
relax and use one fat TemplateVM with the union of all packages I need?

Any advice appreciated.

jh

[awokd]

> However, The VM Manager insists on at least 10 GB for each qube. Giving
> up 100 GB with 75 GB empty (i.e. 15 % of total disk space) is steep. So my
> question is: how can I create smaller images for my qubes?

This is thin provisioned on disk, not dedicated. So you could give each VM
100GB, but if you only put a 1MB file in there, it will only take up 1MB
(+ the filesystem metadata overhead) on disk.

> I'm also open to discussing the basic concept: is it worth trying to
> keep, for example, Firefox and GIMP in separate qubes, or should I just
> relax and use one fat TemplateVM with the union of all packages I need?

I'm partial to small, medium, large approach to templates. The large one
has everything, but never gets a network connection. I wouldn't recommend
HVMs for what you are doing; you lose non-persistence of the root
filesystem.

[Chris Laprise]

awokd is right about root non-persistence... its a good thing to keep. I
only use standalone VMs for rare types of tests.

I'm also not sure that separating large GUI apps from each other in
different VMs is an answer to anything; once you have the layers in
place to support one large app, you probably have most potential
app-related vulns installed at that point.

My personal recommendation is to use debian-9 for most things; create a
larger version with the usual desktop environment (KDE or Gnome) + apps
installed. The smaller one works for sys-net, firewall, vpn, etc. plus
browsing and email. The big one is for content creation and special
comms: office apps, media, messengers, etc.

The isolation concept works best (on Qubes at least) when applied to the
types of _tasks and risks_ you expose each VM to... not so much when
applied to specific apps (although occasionally risk types translate
into specific apps).

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Chris Laprise]

However... in terms of flexible _and_ secure deployment of software,
Qubes could stand some improvement.

I wonder if there are compatible packaging systems that could be adapted
to modular app deployment per-VM. Something like 'snaps' might work.

And the deployment method could be an additional non-persistent volume,
but belonging to each configured VM not the template.

[Jan Hustak]

> I'm also not sure that separating large GUI apps from each other in
> different VMs is an answer to anything; once you have the layers in
> place to support one large app, you probably have most potential
> app-related vulns installed at that point.
>
> My personal recommendation is to use debian-9 for most things; create a
> larger version with the usual desktop environment (KDE or Gnome) + apps
> installed. The smaller one works for sys-net, firewall, vpn, etc. plus
> browsing and email. The big one is for content creation and special
> comms: office apps, media, messengers, etc.

I guess there's a cognitive aspect to it as well, not related to
security as such. I have over 2300 packages installed on my main Debian
notebook, many of them not needed anymore. Cleaning them out is a
tedious job I never get to. If I had a VM/filesystem with "only packages
needed for Project X", things would be more orderly. I don't need Qubes
OS for that, of course, but it's an issue I seek to address in addition
to security. Sorry if I'm straying off topic.

jh

[awokd]

On Thu, April 19, 2018 5:45 am, Jan Hustak wrote:

>
> I guess there's a cognitive aspect to it as well, not related to
> security as such. I have over 2300 packages installed on my main Debian
> notebook, many of them not needed anymore. Cleaning them out is a tedious
> job I never get to. If I had a VM/filesystem with "only packages needed
> for Project X", things would be more orderly. I don't need Qubes OS for
> that, of course, but it's an issue I seek to address in addition to
> security. Sorry if I'm straying off topic.

It's not off topic. I've said before I'd keep using Qubes even if it
provided no additional security over any other Linux distributions (but it
does a lot) merely for the convenience/flexibility it provides! In your
case then, you might want a workflow something like:

1- Clone one of the stock templates to create a base template with common
packages
2- Clone as needed for project X, install specific packages
3- Make Project X AppVM based on the new template
4- Delete project specific VMs when done

If you can figure out a union of common packages (hopefully less than
2300!) then you could skip step #2 some of the time and base #3 on #1.

[cooloutac]

I think its only maximum space. only used when needed. it is already really using only a little more then 4.5 gb each default template vm, i think. you can check in the vm.

[cooloutac]

ya don't hvm is not needed less secure. or if making a standalone hvm no reason to use template. Unless using a special os I also believe there already is a one called debian-minimal or something like that somewhere in community repos.

[Manuel Amador (Rudd-O)]

On 2018-04-16 20:50, Jan Hustak wrote:
> Hello,

> I'm also open to discussing the basic concept: is it worth trying to
> keep, for example, Firefox and GIMP in separate qubes, or should I
> just relax and use one fat TemplateVM with the union of all packages I
> need?
>

Fat template with everything you got there, *so long as your fat
template does not have anything installed that installs systemd system
or user units that will start on boot or login*.  If you have a template
that runs some sort of package on boot or login, you can nuke it using a
systemd unit override (<servicename.d> in the right directory) so it
won't start.  Fedora is really good about not starting units by default
(except for SSHD, which is in fact disabled by default in Qubes templates).

Aaaaaaand then perhaps a thin template for things that could be your
service VMs.  (I'm really rooting for the MirageOS templates).

--
Rudd-O
http://rudd-o.com/

[Jan Hustak]

Yes, this is exactly what I'm thinking about. It does mean having 2 VMs
per project but that's a trivial cost.

jh

[Jan Hustak]

Thanks, that's another angle to consider. My original question concerned
code simply sitting on the disk that could (somehow) be activated by an
attacker - but it's true that a fat template may also mean a busy
runtime with lots of code already active. I do believe the approach
outlined by awokd works to address this issue as well.

Thanks everyone for your responses, they've really been helpful.

jh

P.S. And yes, MirageOS is cool :-)