Re: [qubes-users] Major problems with 3.2, devs must address
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 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/19bdc8f9-b5a5-fe90-8b5f-4b42ace9b984%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Major problems with 3.2, devs must address
On Thu, 6 Oct 2016, 01:15 Andrew David Wong, wrote: > > On 2016-10-05 15:30, boromirsbe...@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 > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CALeQ-zKBPBVzRF7ZFR8Wkc2FPZ%3DbnhZOGG8M3xodXk4sDA0G3Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Major problems with 3.2, devs must address
Am 07.10.2016 um 06:44 schrieb boromirsbe...@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 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0a13d5f0-bbf0-a96b-b757-16841376c5ef%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Major problems with 3.2, devs must address
> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 2016-10-05 15:30, boromirsbe...@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. >> 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- > > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/826b9da6c3cc9456d34f1c27f974319f.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Major problems with 3.2, devs must address
On 10/05/2016 07:15 PM, Andrew David Wong wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-10-05 15:30, boromirsbe...@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 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/69556249-bdd1-9c13-b334-4185098a05ea%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Major problems with 3.2, devs must address
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, boromirsbe...@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) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6d0fccc4-03d5-4756-9524-95bb5e614899%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Major problems with 3.2, devs must address
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-10-05 15:30, boromirsbe...@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- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/89fb4e30-57a6-0815-d311-33766fc1305c%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Major problems with 3.2, devs must address
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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9d268a2a0904c318fa75471cb37db4a1.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.