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
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.
