Qubes 3.2 - templates

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all,

What template versions do we want in Qubes 3.2? The obvious part:
- Fedora 23
- Debian 8
- Whonix 12 (or maybe 13 at that time?)
- Fedora 23 minimal

Not so obvious:
- Debian 8 minimal (that would be first Debian minimal template
release)
- Fedora 22
- Debian 9 (testing)
- Fedora 24 (testing)

This is about availability at all (including updates), not necessary
being included on installation ISO.

My personal opinion is to:
- have Debian 8 minimal
- drop Fedora 22
- don't release Debian 9 template (until Debian 9 final release), but
have packages for it on deb.qubes-os.org (just like in Qubes 3.1).
- the same with Fedora 24

Any other voices?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXKlqfAAoJENuP0xzK19csNdAIAIIVXVAVp7qHnrHoYRsSx2un
2aoKDo54GyroN3ITYCNM6yp2YlXUmvvVjOAuYe6c6aDvQlghqMvs/3AFQKiBvbn/
CYcons9tQLOXBryKU+L1lsE1Xzq92V5UcTQJl2lu6DO5zTQpPLMF3wvFL9TYWsjp
rVgYWVzo3MHC0YuNKWuhZ/zfCdi8StnuEDJ1+d5L6q5y3NblMzwCJTfvBmFcSBpX
SswyUc3gwzoGmflzugFOWTPC3diu0yZ2S6ak3eiCl+iKPRGVw/WKvtm0y7/XQ+KZ
8s93mmpxLN2XZzy4y36r2ZxYZOVPt2Zs1/q3JtGFJ0Aat5S3D/LqOtvCD0Wl4bw=
=/SQi
-----END PGP SIGNATURE-----

[Chris Laprise]

The debian 8 I got a while back was already quite minimal. It would be
nice to have two debian 8 templates like fedora: One with a desktop
environment installed and a minimal one (that is because installing a
template simply labeled "debian 8" and getting zero applications or GUI
tools is confusing).

Having debian9 available would be nice since it is likely to get the
wpasupplicant 2.4 / NetworkManager 1.2 combination that enables the
system to randomize/spoof wifi MAC addresses in a seamless and automatic
way. OTOH, fedora 24 already has these versions of wpasupplicant and
NetworkManager (and my brief attempt to backport them to f23 was
error-free - and, sadly - feature free: The randomization behavior did
not materialize).

TL;DR: f24 is the shortest route I can see right now to a compelling new
privacy feature, which Qubes 3.2 could then claim as well. I suggest
putting it on the front burner.

Chris

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-05-04 13:25, Marek Marczykowski-Górecki wrote:
> My personal opinion is to: - have Debian 8 minimal - drop Fedora
> 22 - don't release Debian 9 template (until Debian 9 final
> release), but have packages for it on deb.qubes-os.org (just like
> in Qubes 3.1). - the same with Fedora 24
>

I agree. However, it's worth noting that Fedora 24 is currently
scheduled to be released much sooner (2016-06-14) than Debian 9 (some
time after 2017-02-05). I would consider the availability of a Fedora
24 template shortly after the release date "nice to have" but not
essential.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXKntVAAoJENtN07w5UDAwiR4QAKOWnkO3EWrf+5D+MG/DKkgx
ZnbYoZe70Bs9ENAyjebIKoOyOOqno0FiU1K6ykeXrzWtdz6rVR15a0gkmdwWEfdn
zU4o7YeU0a2maf9Ypy91qCYjxMh1aWWqWuCwjFejHcFTXV5R6u0urBYNmxwGOua/
mDVOa43YPvjY3dAbGY6jj0c1ceprsNHWrAJHMX//u0KjHFVCtbHcfCcvdbCHv9xd
kRYY7lWdmIKj4CAoaO4EAmxAFfXadjJ2zDcip3pWwAP43NkKZGqja4mDz8aFWhkg
qNRxns8m+E7STPwlH5aslF8nQCrF0UA5Q4O/zx2Fg5XwOac64Uzudv5pdFh3WA49
YRkPi/CYKI2mEhGrBj03TCqAosYcUmT4GoIz1DApGk6toK1jv3MHxL/O54A5KpZG
v+3z2mC7itp+L7HUc3loRp0cxJZC5bmOzBrk0p8xbzfMEiTRY51HDRPkhjTRG4xh
ctiXbqtiUiJ16npJ89Zv0A8kRslNaLhPi6XTBugbxBAv70CpT0f1XG0q//n9oswE
vT7W7ZU+HcfcknU/g5sgBaPqqgYcTml1oRLQEGImfHnDY9mUlEPKX3XZw57QETB7
bNvh+4lCeHj4maOI0y8zqzmI/MUwGUAIUtFdue2qBLwdxlAC71cLx8gm9ATbx93Y
13ytCzaY4r3Xa66+ydkg
=qr6X
-----END PGP SIGNATURE-----

[Patrick Schleizer]

I personally couldn't care less about minimal templates. As per the 80 /
20 rule, they're apparently the "20 % that cause 80 % work" and should
therefore dropped. Or at least allowed to cause as little effort as
possible. Their best use case is geeks. People who think they can be
even more secure by using minimal templates. And then running into lots
of issues and requesting help spending lots of their and others time.
Not something that pays off.

I am unsure about Debian [and Fedora] testing templates, but these may
be useful to allow testers moving forward. (I might use them myself as a
testing base to run 'sudo apt-get install whonix-(gateway|workstation)'
the closer Debian stretch comes. However, also let's not eat it too much
time.

Cheers,
Patrick

[Ivan]

Hi,

On 05/05/2016 06:17 AM, Patrick Schleizer wrote:
> I personally couldn't care less about minimal templates. As per the 80 /
> 20 rule, they're apparently the "20 % that cause 80 % work" and should
> therefore dropped. Or at least allowed to cause as little effort as
> possible. Their best use case is geeks. People who think they can be
> even more secure by using minimal templates. And then running into lots
> of issues and requesting help spending lots of their and others time.
> Not something that pays off.

Not everybody has vast amounts of RAM so minimal templates are
definitively useful when running quite a few VMs without GUI (eg.
network topology or HA/clustering testing, command line tools, ...).

My only gripe with the multiplication of same-distro templates is that
they each download almost identical metadata/packages during update. I'm
wondering how that could be solved (caching proxy ? something more
specific to yum/dnf ?). Right now I have 3 fedora templates - minimal,
standard (qubes' default), and a "heavy" unsecure one with multimedia
stuff and third party yum repos, and it takes quite a lot of bandwidth
to update all of them, often with 90% identical data.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-05-05 00:12, Ivan wrote:
> Hi,
>
> On 05/05/2016 06:17 AM, Patrick Schleizer wrote:
>> I personally couldn't care less about minimal templates. As per
>> the 80 / 20 rule, they're apparently the "20 % that cause 80 %
>> work" and should therefore dropped. Or at least allowed to cause
>> as little effort as possible. Their best use case is geeks.
>> People who think they can be even more secure by using minimal
>> templates. And then running into lots of issues and requesting
>> help spending lots of their and others time. Not something that
>> pays off.
>
> Not everybody has vast amounts of RAM so minimal templates are
> definitively useful when running quite a few VMs without GUI (eg.
> network topology or HA/clustering testing, command line tools,
> ...).
>
> My only gripe with the multiplication of same-distro templates is
> that they each download almost identical metadata/packages during
> update. I'm wondering how that could be solved (caching proxy ?
> something more specific to yum/dnf ?). Right now I have 3 fedora
> templates - minimal, standard (qubes' default), and a "heavy"
> unsecure one with multimedia stuff and third party yum repos, and
> it takes quite a lot of bandwidth to update all of them, often with
> 90% identical data.

Thanks for mentioning this. It's an idea that has been brought up
several times on the mailing lists over the years, but it looks like
we never had an issue to track it, so I've made one:

https://github.com/QubesOS/qubes-issues/issues/1957

>> I am unsure about Debian [and Fedora] testing templates, but
>> these may be useful to allow testers moving forward. (I might use
>> them myself as a testing base to run 'sudo apt-get install
>> whonix-(gateway|workstation)' the closer Debian stretch comes.
>> However, also let's not eat it too much time.
>>
>> Cheers, Patrick

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXKwv7AAoJENtN07w5UDAwlD4QALY1yxby3XHf5wjcxAWxiQUG
4w3KNbDpvkAwQNW8WpUzpoYr20pKwgL5BLJ5HPCP2UpU+AsfmZ+kFDsZYqrVVfG6
AVMbLON1vlk2sBNqEoc3/FN++gGJsa2CHRDp+TxkjODeUB8vYShh4qOtmJ2aSNs2
L/g3RJOYGqQugRjkA6FNiSsMZhFD5mYMF2A9GqVicyYg4W2fnar6R0RzGMBOhlf3
tgLgT76JcwQsiP2tbjKzaA2L636nx1cdKiMqGkLjsRx84xt+fDWmiGotOd4vJsXo
xFLh1PMM1NOxQqK3ZNAArMqGZERgfwbnv05qRvnp0Vve2FMmXyRNYjc3blD9qpSW
rtGu6FTkqnkC9u8dO8VyUOhbBAo4YCmZ91+0NplLzR1mqmD42DcPJ75zt5AWREmz
MPvEoYUvoA/ADmOvpLAdB1dMeye+RGXXtyaIYarQ/gJN1qBozThtgUoDhXB/m7Hh
UO1Elf15nrE8S9YaqezyZjR40AKnVYyQ+JvLH2Nd8UwpZXN2ogTZMgpjYlhFW+Gr
v+ZwB0LHP7+Q3l+LZ3bwUExAIx1IddV6+sZEu3Bh3GDnp0g+GEJ497gfjssY6/zw
3ADzuEz3B2hs5WhQsVFKPLmLntuzs3ooErRe6m/tVb3KjCf1aMcjiq1akyBalkEh
a8iv3o3ABGTB6BtlRHm7
=WjdZ
-----END PGP SIGNATURE-----

[Patrick Schleizer]

Ivan:

> Not everybody has vast amounts of RAM so minimal templates are
> definitively useful when running quite a few VMs without GUI (eg.
> network topology or HA/clustering testing, command line tools, ...).

How much more RAM do minimal templates use?

I would argue, we are better off telling users as advanced as this to
customize the template by uninstalling any undesired packages.

[Ivan]

Hi Patrick,

On 05/05/2016 08:13 PM, Patrick Schleizer wrote:
> Ivan:
>> Not everybody has vast amounts of RAM so minimal templates are
>> definitively useful when running quite a few VMs without GUI (eg.
>> network topology or HA/clustering testing, command line tools, ...).
>
> How much more RAM do minimal templates use?

(I guess you meant the opposite)

It seemed logical that RAM usage is significantly lower without the
bazillion processes running in the background (gfs*, pulseaudio, gnome*,
and whatnot.)

But - your post had me thinking of why one would use minimal templates
in Qubes. The reason in my case is habit - because of years (think 2
decades) of configuring workstations, servers and then VMs with the
lowest RAM/disk usage possible. But since disk space is not really a
concern in Qubes thanks to overlays, it would be perfectly fine to have
a standard template with a systemd state configured with only the
minimal services needed to work fine in Qubes.

> I would argue, we are better off telling users as advanced as this to
> customize the template by uninstalling any undesired packages.

Yes, in addition to documenting the "minimal" systemd state of the
default template.

So yeah, you're right - no minimal template is needed then. The only
downside is having to download more updates than needed for unused
packages, which will be piling up when running many VMs. A caching
mechanism (as discussed in issue #1957) would solve that though.

Cheers,
Ivan

[Holger Levsen]

Hi Marek,

On Wed, May 04, 2016 at 10:25:03PM +0200, Marek Marczykowski-Górecki wrote:
> This is about availability at all (including updates), not necessary
> being included on installation ISO.

ok, cool. availablility is much more important… :)

> My personal opinion is to:
> - have Debian 8 minimal
> - drop Fedora 22

here i'm with you.

> - don't release Debian 9 template (until Debian 9 final release), but
> have packages for it on deb.qubes-os.org (just like in Qubes 3.1).

why not? (also I'm not sure what having those packages there
implies. Would I get other updates as well if I'd enable that repo?)

My goal would be to have Debian stable (8), testing and unstable templates,
all minimal. And oldstable (7) & stable "full" templates. My goal and my
needs.

> - the same with Fedora 24

I'd assume that for people working on/with Fedora, having either Fedora
"stable+1" (so 24 now) and rawhide templates would be equally useful.

Maybe it makes sense to make it obvious, that these development
templates are not stable, either by putting something in their names or
in their repo name…


--
cheers,
Holger

[Franz]

For the average user, not so technical, Sys-net, sys-hub, sys-firewall are based on Fedora-23 and remain that way to avoid headaches. But using Debian for all other ApplVMs, Fedora-23 is kept, and regularly updated only for sys-VMs. So the only reason I see to keep a minimal template is to have a minimal Fedora one on which sys-VMs are based to reduce updates to a minimum.

But, as Patrick noted, if a minimal template is a lot of work, it is certainly enough (and warmly advised) to provide just a script in Fedora template that removes everything except what is strictly necessary for sys-VMs, with clear instructions about how to do that.

In my opinion Qubes should invest less in the hyper-technical that only very few users can appreciate and more on the easy-of-use and audio and video communications easiness that most people use.

Best

Fran

--
cheers,
        Holger

--
You received this message because you are subscribed to the Google Groups "qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20160506085235.GA15115%40matrix.athome.

For more options, visit https://groups.google.com/d/optout.

[Chris Laprise]

On 05/06/2016 07:26 AM, Franz wrote:
>
> For the average user, not so technical, Sys-net, sys-hub, sys-firewall
> are based on Fedora-23 and remain that way to avoid headaches. But
> using Debian for all other ApplVMs, Fedora-23 is kept, and regularly
> updated only for sys-VMs. So the only reason I see to keep a minimal
> template is to have a minimal Fedora one on which sys-VMs are based to
> reduce updates to a minimum.
>
> But, as Patrick noted, if a minimal template is a lot of work, it is
> certainly enough (and warmly advised) to provide just a script in
> Fedora template that removes everything except what is strictly
> necessary for sys-VMs, with clear instructions about how to do that.
>

> *In my opinion Qubes should invest less in the hyper-technical that

> only very few users can appreciate and more on the easy-of-use and

> audio and video communications easiness that most people use.*

>
> Best
> Fran
>
> --
> cheers,
> Holger
>

Debian 8 is working great for service vms on my systems.

Your point about ease of use is very apt. I think ITL should compile a
list of core desktop use cases that it wants to perfect from both a
functional and UX point of view. Having use cases explicitly spelled out
can be surprisingly effective at keeping a project on track, and even
driving development.

Chris

[Chris Laprise]

I can agree with most of this. Its been a long time since running X11
and a handful of desktop daemons has had a subjectively large impact on
RAM use.

My main qualm is that someone installing "the debian template" ends up
with minimal or nearly-so. Most users who rely on the desktop apps will
get thrown off by this.

I'll add that UBUNTU should also be back on the menu... Its the only
truly desktop-focused distro that's been considered for Qubes, while
fedora and debian lack that focus. Qubes probably won't succeed at being
a desktop system itself with just fedora and debian as primary offerings.

Chris

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, May 06, 2016 at 08:52:35AM +0000, Holger Levsen wrote:
> Hi Marek,
>
> On Wed, May 04, 2016 at 10:25:03PM +0200, Marek Marczykowski-Górecki wrote:
> > This is about availability at all (including updates), not necessary
> > being included on installation ISO.
>
> ok, cool. availablility is much more important… :)
>
> > My personal opinion is to:
> > - have Debian 8 minimal
> > - drop Fedora 22
>
> here i'm with you.
>
> > - don't release Debian 9 template (until Debian 9 final release), but
> > have packages for it on deb.qubes-os.org (just like in Qubes 3.1).
>
> why not? (also I'm not sure what having those packages there
> implies. Would I get other updates as well if I'd enable that repo?)

This means you can't install template the easy way (qubes-dom0-update
qubes-template-debian-9), but you can clone debian-8 and dist-upgrade
into debian-9.

> My goal would be to have Debian stable (8), testing and unstable templates,
> all minimal. And oldstable (7) & stable "full" templates. My goal and my
> needs.
>
> > - the same with Fedora 24
>
> I'd assume that for people working on/with Fedora, having either Fedora
> "stable+1" (so 24 now) and rawhide templates would be equally useful.
>
> Maybe it makes sense to make it obvious, that these development
> templates are not stable, either by putting something in their names or
> in their repo name…

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXLTrnAAoJENuP0xzK19cs5LsH/Az1WoNg4py9HKySl7NU55fb
07YF6loGWADQVuhxyyRW1yCNBjyoNpeBRZ2qcystbNgjJVBJQItWD/dXBD4yZsZ+
WnHGbZUocbeSpuJvTQElGXLSQ/KRqiq5g9nhWhlETlQ+ucCCJyEJdwlYG2W4JXpw
DXpEfIXeCgQN7pfZ+rR3kBwXEhMyyKdBJIz2+AXO2D/CfoWZRcQF9X5bfMPqHZ2H
A4pJjAobdhmtT81v6Tbzu2xF0udpE0Lo1cSNZdS4tDl6xE/2hdSyXM3bFXHJTIIz
aM7oU/TuNWQmmUUYxkum5ndZiRG7PUetTQgl0ab2iC5JRoTBSn/HG8brVKQjLSc=
=Pom3
-----END PGP SIGNATURE-----

[Achim Patzner]

On 05/06/2016 04:22 PM, Chris Laprise wrote:

> My main qualm is that someone installing "the debian template" ends up
> with minimal or nearly-so. Most users who rely on the desktop apps
> will get thrown off by this.

Worse: That someone will probably not know hot to update the template
properly.

> I'll add that UBUNTU should also be back on the menu...

To quote the "Life of Brian": He said Jehova...

I've been waiting fot being able to compile it myself for six months
now. It seems nobody really cares. Seems that using the Fedora template
is like drinking Jim Beam -- nobody really likes it but people get used
to it.

> Its the only truly desktop-focused distro that's been considered for
> Qubes, while fedora and debian lack that focus. Qubes probably won't
> succeed at being a desktop system itself with just fedora and debian
> as primary offerings.

!.


Achim

[Holger Levsen]

On Sat, May 07, 2016 at 02:46:31AM +0200, Marek Marczykowski-Górecki wrote:
> This means you can't install template the easy way (qubes-dom0-update
> qubes-template-debian-9), but you can clone debian-8 and dist-upgrade
> into debian-9.

I know I can create my own templates, so maybe this is indeed
sufficient…

Just that I expect to basically daily create stretch and sid VMs…
several times a day :)


--
cheers,
Holger

[Henry de Valence]

On Thu, May 05, 2016 at 03:17:51AM +0000, Patrick Schleizer wrote:
> Their best use case is geeks. People who think they can be
> even more secure by using minimal templates.

In fact there are concrete security benefits to using miminal templates. Here
is one example: since Qubes provides no isolation mechanism other than Xen
domains, the only safe way to open an untrusted PDF is to use a DispVM.
Otherwise, a PDF exploit can take over the entire domain.

As far as I know, the only way to prevent accidentally opening an untrusted PDF
(by, e.g., left-clicking instead of right-clicking, or hitting the wrong key in
emacs which accidentally opens a file link, or ... any of the other 9 million
ways to launch software on a Linux desktop) is to have no installed software in
the template that can open PDFs. Similar considerations apply to all kinds of
other software, e.g., media players, etc.

Moreover, not using minimal templates has performance costs: with the PDF
example, when not using a minimal (DVM) template, each PDF document's DispVM is
running its own abrt-applet, nm-applet, ssh-agent, gnome-keyring-daemon,
gnome-settings-daemon, systemd-journal, etc.

So, I think that there are concrete use-cases for minimal templates to provide
both security and performance benefits.

Cheers,
Henry de Valence

[Unman]

Yes, this is absolutely right. Despite what Patrick says, people *will* be
more secure using minimal templates.
This has been covered on the lists before - some use minimal based qubes
and open ALL attachments etc in non networked qubes based on full
templates. That isn't geeky.

The 20/80 claim is just nonsense. There's no evidence at all that
minimal templates generate significant issues - nothing compared to
whonix/nouveau/proxy/installation problems.

It seems odd to me to disparage geeks when there's current
discussion about implementing awesome.

The current bloat on installation is problematic - why not offer a
number of media? There could be full,(needs usb), basic (fits dvd), and
minimal. It shouldn't take much change to build script to produce these
flavours.

unman

[Jeremias E.]

Hello,

a rolling release distribution based on Archlinux template VM would be awesome.

A rolling release distribution has the advantage of being up-to-date, have new software packages
and it does not require constant version upgrades.

Best regards
  Jeremias Eppler

[Ivan]

On 05/10/2016 03:50 PM, Henry de Valence wrote:
> On Thu, May 05, 2016 at 03:17:51AM +0000, Patrick Schleizer wrote:
>> Their best use case is geeks. People who think they can be
>> even more secure by using minimal templates.
>
> In fact there are concrete security benefits to using miminal templates. Here
> is one example: since Qubes provides no isolation mechanism other than Xen
> domains, the only safe way to open an untrusted PDF is to use a DispVM.
> Otherwise, a PDF exploit can take over the entire domain.
>
> As far as I know, the only way to prevent accidentally opening an untrusted PDF
> (by, e.g., left-clicking instead of right-clicking, or hitting the wrong key in
> emacs which accidentally opens a file link, or ... any of the other 9 million
> ways to launch software on a Linux desktop) is to have no installed software in
> the template that can open PDFs. Similar considerations apply to all kinds of
> other software, e.g., media players, etc.
>
> Moreover, not using minimal templates has performance costs: with the PDF
> example, when not using a minimal (DVM) template, each PDF document's DispVM is
> running its own abrt-applet, nm-applet, ssh-agent, gnome-keyring-daemon,
> gnome-settings-daemon, systemd-journal, etc.

I don't follow your reasoning.

- dispVM can't be based on a minimal template if you expect to be able
to open <quote>all kind of software, eg. media players, etc.</quote>.
Try to install a media player, a pdf reader, libreoffice, ... in a
minimal template to see the dependencies that will be pulled. It won't
be minimal anymore. It wouldn't also be convenient to have a specific
template for each application - eg. a dispPDFVM, a dispMediaVM, a
dispFooVM, ..., so eventually dispVM is going to be quite the same as
the "standard" template.

- the VM you call the disposable VM from will rarely be based on a
minimal template either. Otherwise, how are files supposed to be on that
VM, except without running qvm-copy-vm ? I mean, you'll need a web
browser from which you download stuff, a mail client, ...

The only case I can think of where you would open file from a "minimal"
VM is when you have a non-networked VM for a dedicated use (eg. "vault")
where you copy files with qvm-copy-vm and where you really don't want to
open a pdf/docx/... by mistake. But then you could use a standard
template and simply set $PATH to a folder where you symlink the binaries
you deem safe, assuming you're working in a terminal.
But you mention "right click", which implies using a file application,
which means you're probably already running a few "unsafe" processes
like file preview/thumbnail. Also, having emacs in a minimal template is
not exactly my idea of "minimal", so who gets to decide what would be
installed in the minimal template ?

I guess most users think by habit of minimal templates as a way to
minimize resources (RAM/CPU/disk space). As mentioned in a previous
post, since disk space is not an issue in Qubes, one can probably reach
a similar minimal RAM/CPU footprint by configuring a systemd state
without the stuff you mention (abrt-applet, nm-applet, ...).

>
> So, I think that there are concrete use-cases for minimal templates to provide
> both security and performance benefits.

The minimal template you describe in your PDF example is not minimal -
it has a PDF viewer. User XYZ may not need a PDF viewer in their minimal
template, but an image viewer. And user ABC may not need anything but an
office suite. Etc.
So either the "minimal" template is minimal like Fedora/RH used to have
as an option at install time, or it's "standard" because users have
different expectations and need different programs.

I'm genuinely interested - do you have a concrete use-case with a "real"
minimal template with improved security and performance over a standard
template running in an alternate "minimal" systemd state and with $PATH
set to a folder with symlinked/whitelisted binaries ?

(BTW, this whole discussion is moot if providing minimal templates is
not a burden for Qubes devs, but I remember seeing some issues specific
to those, so it's definitely non-zero).


>
> Cheers,
> Henry de Valence
>
>
>


Cheers,
ivan

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I think you may have misunderstood Henry's description. I'll give an
actual example of a setup I'm using right now.

I'm typing this message from my email VM, which is based on
fedora-23-minimal. The only things I installed on top of the minimal
template were my MUA and a few minor packages like fonts. This VM has
no web browser or PDF viewer. I set all links to open in a different,
untrusted VM (with a web browser), and I set all attachments to open
in DispVMs (which are based on the full template, which has a PDF
viewer installed).

In other words, it's not the DispVM that's minimal; it's my email VM.
The idea is to make it so that I can't accidentally open a malicious
link or PDF in this VM and to minimize the attack surface of this VM.
While my minimal email VM is running all the time, the
full-template-based DispVM is open only while I'm reading a PDF, so
there's less resource usage overall.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXMlNAAAoJENtN07w5UDAwaMIP/Alr65UfDgb4IxvRTLxFyphB
iCoThddDBmwOov9wlbXc7JeNT8wzZam1ub0CyA0Ya36USzDffW1eFxBQpdsqXIt7
yQ/9dow1XgfxfoQCtsnUvsKZv8EbYePF2JltXP7qOLCiwXHEMXB0QX3cdb0vbQ0f
w7bVDpLttCHFs6RT/idp574DjSJ3lWEMMYnUfq67Z6kFGlRpYoTuu5JPYzoABZf5
f3DMd5wDwd7yBGpy0yYZkJoNuXdJr6FpA+vD3icu5epI4lUHlfMSpPXSTEYsy49k
XJAyX7mbgFWisxUeEYY2CkHBf6bm5BoRdTw2v/Rlo20Ch/VLQWcWY7f7ouSSGDjn
qyo6ahQd6uuCtdAFk0oVIlszDzc63FZW7/sLYjGNQmM4sAXsKDk4Ci1UGiMFQs+H
VSCga5IP0kaDR9UrbKM8vhNnuch7kyPszhH7XJIZflxdI87dQyM9KfKzZclqiZay
jgqglNZ9r4geMmrSv5wNHngcX7T1fZ9FzgES4YiAqsgHn1JxXTWjJ0M/tFSjjPP7
LS5O4gh6ogS1We9T4q5y4atIx7SQEFZ5HxkmkqNmZ3xU3/GZv4iz4BfPESIJGABN
B5BrOAGkV8nDLtIw2TIUq3I6aqX6yKYpfM8JEQ8aUxh39IQY0yDwkg2hkeJYAlHs
QR84Ss8Re2EJJabUimvS
=tk4Z
-----END PGP SIGNATURE-----

[Jeremias E.]

Hello Andrew,

your setup should be the default for the email VM.

Best regards
  J. Eppler

[Henry de Valence]

On Tue, May 10, 2016 at 02:31:46PM -0700, Andrew David Wong wrote:
> I think you may have misunderstood Henry's description. I'll give an
> actual example of a setup I'm using right now.

Yes, sorry for any confusion -- this description is exactly what I
meant.

> In other words, it's not the DispVM that's minimal; it's my email VM.
> The idea is to make it so that I can't accidentally open a malicious
> link or PDF in this VM and to minimize the attack surface of this VM.
> While my minimal email VM is running all the time, the
> full-template-based DispVM is open only while I'm reading a PDF, so
> there's less resource usage overall.

Another point is that although the attack surface of the dispVM is
larger, there (should be) no opportunity for persistence, whereas in the
persistent VMs the attack surface (and functionality) is reduced.

Cheers,
Henry

[Manuel Amador (Rudd-O)]

On 05/04/2016 10:44 PM, Andrew David Wong wrote:
> On 2016-05-04 13:25, Marek Marczykowski-Górecki wrote:
> > My personal opinion is to: - have Debian 8 minimal - drop Fedora
> > 22 - don't release Debian 9 template (until Debian 9 final
> > release), but have packages for it on deb.qubes-os.org (just like
> > in Qubes 3.1). - the same with Fedora 24
>
>
> I agree. However, it's worth noting that Fedora 24 is currently
> scheduled to be released much sooner (2016-06-14) than Debian 9 (some
> time after 2017-02-05). I would consider the availability of a Fedora
> 24 template shortly after the release date "nice to have" but not
> essential.
>

I would prefer if it was essential to include F24. It's a pain to use
outdated software.

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

[Manuel Amador (Rudd-O)]

On 05/06/2016 07:29 AM, Ivan wrote:
> Hi Patrick,
>
> On 05/05/2016 08:13 PM, Patrick Schleizer wrote:
>> Ivan:
>>> Not everybody has vast amounts of RAM so minimal templates are
>>> definitively useful when running quite a few VMs without GUI (eg.
>>> network topology or HA/clustering testing, command line tools, ...).
>>
>> How much more RAM do minimal templates use?
>
> (I guess you meant the opposite)
>
> It seemed logical that RAM usage is significantly lower without the
> bazillion processes running in the background (gfs*, pulseaudio,
> gnome*, and whatnot.)

It isn't just logical. It is a fact that I have verified locally.


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

[Chris Laprise]

OK, assuming I am using desktop templates for service vms: How does one
attack sys-net and sys-firewall using pdf files?
:D

Chris

[Ivan]

Thanks for the example, that makes sense. I now understand better what
Henry had in mind in the first two paragraphs of his post (the last part
about dispVM resources still seems to advocate using disp VMs with
minimal templates though).

Cheers,
Ivan

[Unman]

I would love to tell you, but then, of course, I'd have to kill you.

The point is, of course, that it isn't pdf *files* that are the problem
for service qubes. It's the libraries, helper programs and so on that
are installed if you are running a system capable of parsing and
displaying PDF files.

Look at any decent security device and it's stripped as far as possible
- unnecessary programs and services removed, libraries cut and kernel
tweaked to minimum.
I don't see why the same shouldn't be done for service qubes.

Of course, with qubes, one isn't concerned by privilege escalation, but
the possibility of chaining exploits remains, and that's why it makes
sense to limit the scope.

In the case of normal qubes,(work,email), I see it as as important a
part of securing the environment as the firewall. Just as the firewall
secures against unintentional leaks, so use of a minimal template
secures against both unintentional and intentional leaks.
If the qube has the program installed then there's a risk that the user
will open it by mistake - use of a minimal template ensures that a user
doesn't open a potentially malicious program in the home qube.

unman

[Chris Laprise]

I think its precisely these sorts of non-isolation security tactics that
ought to be recognized for their limited scope. What you say makes sense
in certain contexts, such as when using various high-level applications
and data-oriented utilities. I don't think it quite reaches into the
operational domain of regular service vms... if for no other reason than
the associated Qubes UIs do not invite accidental opening of files in
service vms (but there are other reasons).

What's right about the default Qubes installation is that a template
configured for a reasonably full desktop experience is utilized... this
represents a balance between elegant simplicity and functionality, and
against unnecessary duplication and demands on the users' attention.

What's wrong about the concept of "minimal template" is that every
single specific task has its own unique requirement for minimalist
security. Qubes already has a tendency to generate a kind of 'template
pollution' by the user in the course of regular use. Exacerbating that
tendency with a poorly-defined ethic of minimalism could just make it
worse for little or no benefit (remembering that we're not talking about
dom0 minimalism here).

We already know the desktop templates are intended to fulfill the role
of general desktop use. Assuming that minimal templates have any part to
play in enhancing Qubes security, there should be an explicit
understanding of what roles a minimal template serves, and what it needs
to include to be useful enough, and when starting with minimal is
gratuitous and poor form. The worst possible outcome is to have a
culture develop without this understanding, and start to develop docs
and howtos that habitually tell people to "1. Clone minimal template"
because it makes good security theater. What that leads to is ugly and
confusing, and improves domain isolation not one iota.

Chris

[timcol...@gmail.com]

BTW - 3.2 install was buttery smooth vs 3.1 and the interface is spot on - basically this is what Qubes experience has been most frustrating - just the struggle to get it up and running - AMAZING job! Im referring to the test 20160607 ISO btw.

On Wednesday, May 4, 2016 at 4:25:13 PM UTC-4, Marek Marczykowski-Górecki wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all,

What template versions do we want in Qubes 3.2? The obvious part:
 - Fedora 23
 - Debian 8
 - Whonix 12 (or maybe 13 at that time?)
 - Fedora 23 minimal

Not so obvious:
 - Debian 8 minimal (that would be first Debian minimal template
   release)
 - Fedora 22
 - Debian 9 (testing)
 - Fedora 24 (testing)

This is about availability at all (including updates), not necessary
being included on installation ISO.

My personal opinion is to:
 - have Debian 8 minimal
 - drop Fedora 22
 - don't release Debian 9 template (until Debian 9 final release), but
   have packages for it on deb.qubes-os.org (just like in Qubes 3.1).
 - the same with Fedora 24

Any other voices?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXKlqfAAoJENuP0xzK19csNdAIAIIVXVAVp7qHnrHoYRsSx2un
2aoKDo54GyroN3ITYCNM6yp2YlXUmvvVjOAuYe6c6aDvQlghqMvs/3AFQKiBvbn/
CYcons9tQLOXBryKU+L1lsE1Xzq92V5UcTQJl2lu6DO5zTQpPLMF3wvFL9TYWsjp
rVgYWVzo3MHC0YuNKWuhZ/zfCdi8StnuEDJ1+d5L6q5y3NblMzwCJTfvBmFcSBpX
SswyUc3gwzoGmflzugFOWTPC3diu0yZ2S6ak3eiCl+iKPRGVw/WKvtm0y7/XQ+KZ
8s93mmpxLN2XZzy4y36r2ZxYZOVPt2Zs1/q3JtGFJ0Aat5S3D/LqOtvCD0Wl4bw=
=/SQi
-----END PGP SIGNATURE-----