Major problems with 3.2, devs must address

[boromi...@sigaint.org]

Alot of this is posted on the reddit.com/r/qubes board, there are alot of
problems with 3.2, both security + function.


1. Dom0 is exposed to Sata connected drives. This is evident when running
qubes on a usb connected drive going into dom0 file manager, the sata
drive is automatically mounted and exposed to dom0. Part of Tails security
is to require auth and manual mounting of locally connected drives, if
this is not necessary for some reason users are owed an explanation.

2. Attaching USB controller to a usbVM (running qubes on a sata connected
disk), renders all vm's unable to start, even after controller is
detatched. Short-term remedy is to detatch and reboot. My entire equipment
hierarchy is intel, recent hardware, compatibility should not be an issue.

3. Installing a printer produces an authentication window when attempting
to add a printer. The documentation doesnt provide what those login
details are, attempting to use ones user login credentials is denied.

Also there are some minor issues that should be addressed:

4. Two [Dom0 monitor configuration] windows pop up everytime a VM is started.

5. VM manager signals that dom0/templates require updates even when it
reports there are no updates in the update window.

[Andrew David Wong]

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

On 2016-10-05 15:30, boromi...@sigaint.org wrote:
> Alot of this is posted on the reddit.com/r/qubes board, there are alot of
> problems with 3.2, both security + function.
>
>
> 1. Dom0 is exposed to Sata connected drives. This is evident when running
> qubes on a usb connected drive going into dom0 file manager, the sata
> drive is automatically mounted and exposed to dom0. Part of Tails security
> is to require auth and manual mounting of locally connected drives, if
> this is not necessary for some reason users are owed an explanation.
>

I believe this is what the dedicated storage domain (which we're currently
working on implementing) is meant to handle:

> 2. Attaching USB controller to a usbVM (running qubes on a sata connected
> disk), renders all vm's unable to start, even after controller is
> detatched. Short-term remedy is to detatch and reboot.

Thanks for the report! Tracking:

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

> My entire equipment hierarchy is intel, recent hardware,
> compatibility should not be an issue.

Often times, recent hardware is less compatible than older hardware. This
seems to be true generally in the Linux world, not just with Qubes. It
takes a little while for software support to catch up to the newer hardware
(in contrast to the Windows world).

> 3. Installing a printer produces an authentication window when attempting
> to add a printer. The documentation doesnt provide what those login
> details are, attempting to use ones user login credentials is denied.
>

This sounds like something specific to your printer or to CUPS, not a
Qubes-specific issue.

> Also there are some minor issues that should be addressed:
>
> 4. Two [Dom0 monitor configuration] windows pop up everytime a VM is started.
>

Thanks. Tracking:

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

> 5. VM manager signals that dom0/templates require updates even when it
> reports there are no updates in the update window.
>

These are being tracked here:
https://github.com/QubesOS/qubes-issues/issues/2086
https://github.com/QubesOS/qubes-issues/issues/2009

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

iQIcBAEBCgAGBQJX9YmpAAoJENtN07w5UDAwH50QAIvIDspxMoUsDcLoes6uC2mJ
/dfLRvIXwAph6suFgHvFExggmfuxkWbm5aSopoCztyPUHyy5PKBhRfrO4dfOBpWj
8o0TFB6IjWkJVr54R8OfcJOfvPIoRlpT8YH8u140IQZ4cJGefeHqxi9nrVX7v5iH
TTx8PnyGDFe3IjkXXHMVRAtfFbwG06dCsKE4pqSupKWXl8v3akgOYC0KF7zMeQ0c
9IboKlcOTHsF7BWU9YlkJYq8BpQlCBMzdmfxYgJeASJWkglrTVUUAqq3dmF/+Q5k
bdHjeJTPr1/RZhItpZi6q2HQZSY7O5RGhGuhprmqK02+oQfM4RQIPu42Mqlb+gtP
H5R5biS1DBWeIQfNEnq84AKUKyNKBuZ3yxXukkQB7IHJMYKLrgDOk4anbYUCg4Ky
Chp3MOD0ma741vZEqRGI4MVP3lK8Xe2teqEtO8J+ugh9/b83PTMQqfMY1HNupxl6
NwamX58oymv0iWJl+OUslXULe/PK424pHM8QkXlqSrQd8xd9ykbslHPFPLoGggjk
UhEOlR0SJFDXzie3ZP+aYktqfiTnqUej1kqUmPiV8ReoaA4FXWcziXu6ZShDrJ6o
lkcHN3EZAdYgAPCC4CtWbvcsWaxvp/+akYkyc31+aA4P3VymLnpjibCQdk9IkQ4O
YIDTGf/cGBLjTnEV/abD
=ErI3
-----END PGP SIGNATURE-----

[Drew White]

On Thursday, 6 October 2016 10:15:59 UTC+11, Andrew David Wong wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 2016-10-05 15:30, boromi...@sigaint.org wrote:
> > Alot of this is posted on the reddit.com/r/qubes board, there are alot of
> > problems with 3.2, both security + function.
> >
> > 1. Dom0 is exposed to Sata connected drives. This is evident when running
> > qubes on a usb connected drive going into dom0 file manager, the sata
> > drive is automatically mounted and exposed to dom0. Part of Tails security
> > is to require auth and manual mounting of locally connected drives, if
> > this is not necessary for some reason users are owed an explanation.
> >
>
> I believe this is what the dedicated storage domain (which we're currently
> working on implementing) is meant to handle:

Will this be optional?

> > 2. Attaching USB controller to a usbVM (running qubes on a sata connected
> > disk), renders all vm's unable to start, even after controller is
> > detatched. Short-term remedy is to detatch and reboot.
>
> Thanks for the report! Tracking:
>
> https://github.com/QubesOS/qubes-issues/issues/2367

Could you elaborate this issue?
As to hardware and how many controllers you have as well as details on what you do to attach it to the USBVM?

I have a USBVM, I don't use the USBVM kernel or addition provided by Qubes.
I just have the PCI attached to the VM.

Issue with the USBVM not starting was the pci_strictreset option. I had to disable it.

Never affected any other VM though.

> > My entire equipment hierarchy is intel, recent hardware,
> > compatibility should not be an issue.
>
> Often times, recent hardware is less compatible than older hardware. This
> seems to be true generally in the Linux world, not just with Qubes. It
> takes a little while for software support to catch up to the newer hardware
> (in contrast to the Windows world).
>
> > 3. Installing a printer produces an authentication window when attempting
> > to add a printer. The documentation doesnt provide what those login
> > details are, attempting to use ones user login credentials is denied.
> >
>
> This sounds like something specific to your printer or to CUPS, not a
> Qubes-specific issue.
>
> > Also there are some minor issues that should be addressed:
> >
> > 4. Two [Dom0 monitor configuration] windows pop up everytime a VM is started.
> >
>
> Thanks. Tracking:
>
> https://github.com/QubesOS/qubes-issues/issues/2368

Could you please elaborate this bug?
I used to run 2 monitors, recently upgraded to 4, I've run KDE and XFCE on both.
Never experienced this "issue".

> > 5. VM manager signals that dom0/templates require updates even when it
> > reports there are no updates in the update window.
>
> These are being tracked here:
> https://github.com/QubesOS/qubes-issues/issues/2086
> https://github.com/QubesOS/qubes-issues/issues/2009

I found that this is often caused (for me here) by the data cached from previous updates, it is update but doesn't think it is.

I cleared my update cache and that resolved the issues, since DNF is used instead of YUM, where Qubes talks to YUM instead of DNF. There is some confusion in the system in that relation. (This is what I found to work and what I thought it must be, may not actually be the answer/reason)

(I've had more issues with Qubes than most people, and MANY of my issues have NEVER been resolved and SOME have never even gotten attention from the people at Qubes. (So issues since version 2.0 are still here)

[Chris Laprise]

On 10/05/2016 07:15 PM, Andrew David Wong wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 2016-10-05 15:30, boromi...@sigaint.org wrote:
>> Alot of this is posted on the reddit.com/r/qubes board, there are alot of
>> problems with 3.2, both security + function.
>>
>>
>> 1. Dom0 is exposed to Sata connected drives. This is evident when running
>> qubes on a usb connected drive going into dom0 file manager, the sata
>> drive is automatically mounted and exposed to dom0. Part of Tails security
>> is to require auth and manual mounting of locally connected drives, if
>> this is not necessary for some reason users are owed an explanation.
>>
> I believe this is what the dedicated storage domain (which we're currently
> working on implementing) is meant to handle:

Wanted to mention here that it mainly comes down to DMA attacks from
compromised HD/SSD firmware. In a legacy/BIOS configuration, the
auto-mounting part only involves one internal partition (/boot) and you
have the option of protecting it with AEM... if it works.

SATA buses rarely have the kind of plug-and-play, external profile that
USB has, so a physical attack where the case is opened is probably
necessary. And even then it would probably be an active one, not a
passive one where malware can just migrate between USB devices in a
sneakernet fashion.

Hotswap drive bays might raise the risk to USB levels, but that's a
pretty rare situation on a PC.

>
>> 2. Attaching USB controller to a usbVM (running qubes on a sata connected
>> disk), renders all vm's unable to start, even after controller is
>> detatched. Short-term remedy is to detatch and reboot.
> Thanks for the report! Tracking:
>
> https://github.com/QubesOS/qubes-issues/issues/2367
>
>> My entire equipment hierarchy is intel, recent hardware,
>> compatibility should not be an issue.
> Often times, recent hardware is less compatible than older hardware. This
> seems to be true generally in the Linux world, not just with Qubes. It
> takes a little while for software support to catch up to the newer hardware
> (in contrast to the Windows world).

On top of that, how its all put together matters as much as who made the
parts. There was never really such a thing as "PC Compatible" in
personal computing... It was either Mac, or "IBM compatible" which
shifted to "Windows compatible". Where Linux, Xen, etc fit in is in the
subset of models where the vendor desires to use the most 'vanilla'
(non-cost-reduced) chips, and that is sometimes a function of catering
to business Linux users on the side.

Where Linux, Xen, etc do NOT fit in is when a PC is designed as cheap
consumer goods or hobbyist "performance rig" and its more profitable to
hire a couple engineers to iron out the wrinkles with those funky
drivers containing the workarounds that make hardware with half-broken
and hidden shortcuts appear functional. Their target in that case is one
and only one thing: Windows. (And yes, the crummy cost-reduced chips and
firmware are based on older designs, so they often kinda-sorta work with
existing Linux drivers. But chances are you will never get to scratch
that itch of having everything work with Linux on that discount consumer
PC.)

So the best choices are usually Linux-dedicated brands, and certain
business models from top-tier brands. If you want to depart from that
(not very small) selection flying your "PC compatible" and "homemade
rig" flags while carrying the burden of Qubes' additional hardware
requirements, well, don't expect much.

Chris

[boromi...@sigaint.org]

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 2016-10-05 15:30, boromi...@sigaint.org wrote:
>> Alot of this is posted on the reddit.com/r/qubes board, there are alot
>> of
>> problems with 3.2, both security + function.
>>
>>
>> 1. Dom0 is exposed to Sata connected drives. This is evident when
>> running
>> qubes on a usb connected drive going into dom0 file manager, the sata
>> drive is automatically mounted and exposed to dom0. Part of Tails
>> security
>> is to require auth and manual mounting of locally connected drives, if
>> this is not necessary for some reason users are owed an explanation.
>>
>
> I believe this is what the dedicated storage domain (which we're currently
> working on implementing) is meant to handle:

Ok my concern mostly is because its my windows disk and i dont trust it,
but another user said that sata disks dont have the same risk of passive
attacks at usbs for some reason.

>
>> 2. Attaching USB controller to a usbVM (running qubes on a sata
>> connected
>> disk), renders all vm's unable to start, even after controller is
>> detatched. Short-term remedy is to detatch and reboot.
>
> Thanks for the report! Tracking:
>
> https://github.com/QubesOS/qubes-issues/issues/2367
>
>> My entire equipment hierarchy is intel, recent hardware,
>> compatibility should not be an issue.
>
> Often times, recent hardware is less compatible than older hardware. This
> seems to be true generally in the Linux world, not just with Qubes. It
> takes a little while for software support to catch up to the newer
> hardware
> (in contrast to the Windows world).

Except that i broke down and used the usb anyways (its my tails usb) and
it connects and transfers just fine, as does my qubes which is running off
a usb drive now. The problem is in the attaching it to a vm part. I dont
know if im the only one but this does throw the whole new 3.2 usb
virtualization feature into the garbage.

>
>> 3. Installing a printer produces an authentication window when
>> attempting
>> to add a printer. The documentation doesnt provide what those login
>> details are, attempting to use ones user login credentials is denied.
>>
>
> This sounds like something specific to your printer or to CUPS, not a
> Qubes-specific issue.
>

This is not specific to my printer, i used it fine in Tails, the OS asked
me in tails for a login/pass to install a printer, this is not printer
specific, i dont even have to have a printer connected in qubes for this
to happen. In tails i would set an admin password prior to logging in and
then use that to add printers, in qubes it asks for this but does not
accept my user account login info. Add the 'print settings' program to
whonix-gs template and try to add a printer, it will ask for a login/pass.
This is really frustrating if there is some way to disable this or if you
can ask the developer what the login/pass is i really need to use my
printer.

[Achim Patzner]

Am 07.10.2016 um 06:44 schrieb boromi...@sigaint.org:
> Ok my concern mostly is because its my windows disk and i dont trust it,

If you're not using a dedicated machine for Qubes instead of booting
multiple operating systems with definitely lower security standards
anyway I don't see your problems at all as this is only a minor problem
in that kind of environment. The same applies to Tails – it's generally
a good idea to stop trusting a machine that has been running something
like Windows if your security requirements prompt you to consider
attacks coming from the firmware of a possibly compromised SATA device.

> > This is not specific to my printer, i used it fine in Tails, the OS
> asked
> > me in tails for a login/pass to install a printer, this is not printer
> > specific, i dont even have to have a printer connected in qubes for this
> > to happen.

Part two of the answer before: This is probably a CUPS-related problem;
as soon as you're dealing with the CUPS server itself (instead of the
tools that modify the CUPS configuration files) you'll be running into
this. Either keep your fingers off the web interface, editing the
configuration files with an editor or (ironically using the same editor)
modify the authentication requirements of the configuration files
appropriately for the web interface to permit you to use it (keep in
mind that "user" does not have a password so you'll have to do quite
some cleaning).

> In tails i would set an admin password prior to logging in and then
> use that to add printers, in qubes it asks for this but does not
> accept my user account login info.

because the account on the virtual machine is not the login account of dom0

Always keep in: Qubes is not Tails. Not by far.


Achim

[Pablo Costa]

On Thu, 6 Oct 2016, 01:15 Andrew David Wong, <a...@qubes-os.org> wrote:

On 2016-10-05 15:30, boromi...@sigaint.org wrote:

> 3. Installing a printer produces an authentication window when attempting
> to add a printer. The documentation doesnt provide what those login
> details are, attempting to use ones user login credentials is denied.
>

This sounds like something specific to your printer or to CUPS, not a
Qubes-specific issue.

If the "authentication window" is produced by CUPS (I usually manage CUPS with a browser to http://localhost:631 ), then a set of credentials that will work are root plus any non-empty random password.

I have a personal hate-based relationship with CUPS. From what I remember, CUPS as we know it in the GNU+Linux world, is some kind of aborted Frankenstein built by Apple which they have probably evolved or caged/wrapped in MacOS, buy we deal with it face to face over the counter. In special (but not the onky reason) I despise it because it (by default?) requests the root credentials and you are expected to supply them to a web browser.

BTW, I remember disabling the CUPS service on my templateVMs, because it used to be running by default on every VM and DispVM. I don't know if this is still the case.

Cheers,

pablo

[Achim Patzner]

Am 09.10.2016 um 11:39 schrieb Pablo Costa:

> (I usually manage CUPS with a browser to http://localhost:631 )

Real men don't use the web administration interface. Real men use vi.
8-) (Which, incidentally, is the only way to deal with CUPS without
losing your mind).


Achim