Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS
On Sat, May 13, 2017 at 02:55:12PM -0500, Andrew David Wong wrote: > > you really dont protect your gpg key with a passphrase?? > See: https://www.qubes-os.org/doc/split-gpg/ oh wow :( > Why is that a problem? It's only visible in dom0. If an attacker is in > dom0, it's already game over. no, the world is not black and white. If an attacker steals your computer while it's unlocked, all your gpg encrypted stuff is wide open. If an attacker steals my computer while it's unlocked, my gpg encrypted stuff is still locked. Surely the attacker can now install as many backdoors as they want, but as long as I don't type my gpg passphrase into that computer anymore, it should be pretty safe. -- cheers, Holger -- 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/20170514085123.GC13184%40layer-acht.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[qubes-users] Re: Upgraded Fedora-23 template to Fedora-25 ... "Houston, we have a problem!"
Many thanks Grzesiek! It seems there's a command line tool to handle the menu, so it can be done this way: sudo xdg-desktop-menu uninstall fedora-23-vm.directory fedora-23-qubes-appmenu-select.desktop Those latter two identified by looking in the directory you specified, /etc/xdg/menus/applicaitons-merged and reading the fedora-23-vm.menu file. -- 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/5a829b00-7e20-4fff-8215-5ffc1635b579%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] debian minimal
Hi Unman & ubestemt, thank you for your patience. I followed Unmans hints. The difference is that, due to no-full-fedora-appvm-working-error I was using a f-24-minimal als starting point. This is bad, since minimal means minimal.. so the setup script failed miserably several times without surprise. The first ones seemed easy. I added dialog, dialog-devel. Then it was dpkg-dev and debootstrap that were missing. Got them as well. Since gpg is used & installed I added as a guess additionally openssl & openssl-devel as well. Now I am stuck: Setup spills out Traceback (most recent call last) File ./setup, line 1919 in main(sys.arg) File ./setup, line 1902, in main Wizard(DialogUI(), **args)** File ./setup, line 1190 in __call__ self.verify_keys(self.keys, force=False) File ./setup, line 1233, in gpg-verify_key _env=env .. UnicodeDecodeError: 'ascii' code can't decode byte 0xc3 in position 91: ordinal not in range(128) This error, as suggested here https://stackoverflow.com/questions/21129020/how-to-fix-unicodedecodeerror-ascii-codec-cant-decode-byte is due to some coding problems. Maybe some 'errors' in the setup script never appear in a rich-fedora system, but fail in fedora-minimal? I have no clue how too fix that. Anyone might help? Bernhard -- 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/fc72dc9f-e4ce-4ef7-e609-2380e533c73b%40web.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] USB Hubs + sys-usb
Ive been using qubes for quite a while. Recently i wanted to pass my USB-Sound device to a appVM, which is located within a Powered Hub. I noticed that qvm-usb didn't display it at all. But a USB Storage device was accessable via the qubes-manager to attach to a appVM. --- Location of issue: /usr/lib64/python2.7/site-packages/qubes/qubesutils.py lines: 472 , 473 usb_device_re = re.compile(r"^[0-9]+-[0-9]+(_[0-9]+)?$") usb_port_re = re.compile(r"^$|^[0-9]+-[0-9]+(\.[0-9]+)?$") As a temporary fix I replaced the above lines with: usb_device_re = re.compile(r"^[0-9]+-[0-9]+(_[0-9]+)+$") usb_port_re = re.compile(r"^$|^[0-9]+-[0-9]+(\.[0-9]+)+$") --- Now devices in a powered USB-Hub show up for me as. 2-1.1.1.1 -> 2-1.1.1.6 (first hub) 3-1.1.1.1 -> 3-1.1.1.4 (2nd hub) Hopefully this is of help to someone else and Devs can look after a more permanent fix for this issue. Additionally some Microsoft USB devices include the registered symbol in the USB Desc text, this causes qvm-usb to fail to display at all. Issue is in same file as before but on line 474, temp fix for anyone with such issues replace [ -~] with [ -~(\x20-\xE0)] kinda defeats the purposes of the usb_desc_re regex but atleast they display with qvm-usb now. -- 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/5bf0b034-5886-4a5e-b140-bb27d19ee445%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: android on a vm
HI drew, i tried to install different versions of android and all of them boot succesfully but when I try to reboot the hvm it stucks at the boot screen saying "booting from hard disk." So i googled something and I've found that maybe the problem could be the xen hypervisor that must be changed with the nested virtualization adding two line of code in the config file, but I didn't get where to find this file and if is a vm's file or a qubes one -- 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/84600390-e0b1-4607-98e3-e8285cf6d9d8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Laptop with discrete graphics card, any chance it'll work?
On 05/13/2017 01:07 PM, loke...@gmail.com wrote: I'm aware of this, which is why I said that I'm ok with installing Nvidias drivers. If I understand you correctly, you're suggesting that this is not an option? Assuming that Noveau will eventually support it, will it be possible to to utilise the GPU in a vm at that time? No it won't, you would need an external gpu that you would attach to the VM. Nouveau probably won't support the new chips anytime due to nvidia refusing to release the binary blobs required to make it work (and blobs are terrible anyway, they also have hardware code signing enforcement) and not releasing documentation making development very difficult https://www.phoronix.com/scan.php?page=news_item&px=Initial-Nouveau-Pascal Using nvidia's drivers is difficult, especially with qubes. I would get a laptop with AMD graphics instead, or get an older model like the T430 or W530 (and you can install open source init coreboot on that) -- 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/1819efdf-2634-919f-8ecb-257dbf28eab3%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-05-13 18:39, cooloutac wrote: > On Saturday, May 13, 2017 at 3:50:36 PM UTC-4, Andrew David Wong > wrote: On 2017-05-09 14:54, cooloutac wrote: On Tuesday, May 9, 2017 at 1:40:03 AM UTC-4, Andrew David Wong wrote: On 2017-05-08 23:47, cooloutac wrote: >>> On Tuesday, May 9, 2017 at 12:47:11 AM UTC-4, >>> cooloutac wrote: On Sunday, May 7, 2017 at 12:33:54 PM UTC-4, nick...@kulinacs.com wrote: > On May 7, 2017 10:39:22 AM CDT, Andrew David Wong > wrote: >>> On 2017-05-07 10:32, nickl...@kulinacs.com wrote: On May 7, 2017 10:23:54 AM CDT, Andrew David Wong wrote: On 2017-05-07 10:10, nickl...@kulinacs.com wrote: >>> What benefit does this have over simply >>> ysing qubes-split-gpg-client-wrapper, >>> like done here: >>> https://github.com/kulinacs/pass-qubes >>> It seems like a lot of overhead for not >>> a lot of gain. >>> >>> On May 7, 2017 9:50:26 AM CDT, "Manuel >>> Amador (Rudd-O)" >>> wrote: Building on the excellent pass (https://passwordstore.org), it gives me great pleasure to announce the initial release of qubes-pass — an inter-VM password manager and store for Qubes OS. Check it out here! https://github.com/Rudd-O/qubes-pass What are the advantages of either of these over the traditional Qubes model of having a normal password manager in a vault VM and using the inter-VM clipboard to copy/paste passwords out of it? I prefer Pass because it uses GPG for encryption, meaning I can manage fewer secrets over all (as it backends into my normal GPG key) and then track my password files in git. To do this with the traditional Keepass method, you either need to back up the password database somewhere secure or remember another password for it. >>> >>> Why not just back up the entire vault with qvm-backup? >>> > > Git has less storage overhead (as you're backing > up a bunch of text files, not an entire VM), > allows proper versioning, so it is trivial to see > your passwords at a point in time, and can be used > cross platform if you chose to keep your GPG key > on another system. I just back up the database file. its encrypted. >>> >>> I don't think backing up the whole vault is a good >>> idea if you don't have to. >>> Why? No need to encrypt the database file if the whole VM is encrypted. Also, if your database file doesn't use authenticated encryption, that's another thing to worry about. You may also worry about file-level metadata leakage. the database file is automatically encrypted. I just feel like vault more likely compromised then the file if something is. but I could be wrong. plus way less space. > > I don't see any basis for that reasoning. The files in an AppVM are > only as safe as the AppVM itself, unless the VM is used only for > storage or something. > > If the vault VM is compromised, then the encrypted database file in > the vault is only safe as long as it remains encrypted. An attacker > who can compromise your vault can set a trigger that waits for you > to decrypt the database the next time you want to use it, then grab > the passphrase, decryption key, or the whole decrypted database. > I think when we have paranoid mode it will be better. > > > Because more attack vector. Seems like common sense for me. The > whole point of paranoid mode isn't it? > What do you mean? Are you suggesting that qvm-backup has "more attack vector" than an encrypted KeePassX (or whatever) database? Why? > As for attacker getting the key to the database file thats fine, > in other words you also assume like I would that they are not > turning it into malware itself. No, I think it's actually the opposite. An attacker could feed you a malformed database file, which you believe is your authentic database file. If it's not authenticated, you won't be able to tell. When you try to decrypt and open it with KeePassX, it could try to compromise KeePassX. qvm-backup is designed to protect against this class of attack. > Even if they got the key thats fine if you are just using it to > change your passwords using a new database and new key. > I'm not sure what you mean. If an attacker has a copy of your encrypted datab
Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-05-14 03:51, Holger Levsen wrote: > On Sat, May 13, 2017 at 02:55:12PM -0500, Andrew David Wong wrote: >>> you really dont protect your gpg key with a passphrase?? >> See: https://www.qubes-os.org/doc/split-gpg/ > > oh wow :( > >> Why is that a problem? It's only visible in dom0. If an attacker is in >> dom0, it's already game over. > > no, the world is not black and white. > > If an attacker steals your computer while it's unlocked, all your gpg > encrypted stuff is wide open. > > If an attacker steals my computer while it's unlocked, my gpg encrypted > stuff is still locked. Surely the attacker can now install as many backdoors > as > they want, but as long as I don't type my gpg passphrase into that computer > anymore, it should be pretty safe. > You're conflating two distinct problems: (1) Passphrases I've typed in dom0 are available in cleartext in dom0. (2) Data-at-rest is not encrypted while Qubes is booted and the screen is unlocked. We could solve (1) without solving (2). If we did that, it would solve the `ps` + qvm-backup problem (the first problem you mentioned), since my backup would be encrypted, and the thief wouldn't have access to the backup decryption passphrase. (2) is the second problem you mentioned. Solving (2) is distinct from solving (1), but in order for the solution to (2) to be satisfactory, we also have to solve (1) (or make sure no similar problem arises for per-VM encryption), since otherwise my data-at-rest passphrase could be obtained via (1). I think the right approach to (2) in Qubes is per-VM encryption [1] (probably with LUKS instead of GPG, and certainly not relying on public key crypto, though hopefully we're all already in agreement on the latter point). If I'm in an untrusted physical environment, I should be able to work with less sensitive VMs without decrypting sensitive VMs, and if someone steals my unlocked laptop, they shouldn't be able to gain access to the encrypted sensitive VMs. That's the goal, anyway. [1] https://github.com/QubesOS/qubes-issues/issues/1293 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJZGLwgAAoJENtN07w5UDAwAbQP/juQIolMCIFVF8m+MP4pAOkK 2AssF3W2S9ta9HBj5zFQNxCPrkkg/cF0rK78iB5C4QevU/vXlGQSbtmudQL8vejV S/tEXPQQZCpU9+9HOXkAAUSXGYxd8rr5j6xtUx5j+GwBV/1RFH1GEyzDAafU/bZR 7Sa8t0HPx6pjOPst85i0Fg++qmka/t0aBjTrjwk63LijqBZXz8FBpeQKdqAzv8Ip he6/EpDSRP7H6VRuIm8iFeYs/6ohFOemesp8BMF7tcPYxOI68rQTtzdgpSYIf4ve oALypvQ1oDJt8z/TKckbrGlIk5lYJfOuKq3/4MkyoZxM8V24yKPNaeeoyiEsLvOH QrnBzyBSbxMIZnuHfNyTb5QGn+YM511hHaGQFSxqCPsSD4orVmuXpnJsm2YdEXeU iChHyzdfsUrWOeh1TgqnfQ078AvK3JZKMwHwOYucYERgSMu5yUFjS57yv60FdmsH yXl5S+I9CThKdr9y8mHq8GujEOlMjMG7eqlA8Q/Up48T7RQnHF8Ivrntkiwb4pBb B2iciTO5KZ+JhcPqoNp/NPCvv3G4R2s0vtFF8QO3nMFjczVv9D3hrockRBEh7rkz HMVaobICdqMKemHF4Dg30gqG5V9WDpiMwFybj2x339SoOLb6E3rMJ+YH3hM+vvVm Bd5Hzi2hwvaAD/S31BZx =6VoB -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/dfbbdb3b-7dab-f4ce-7c78-7991675f1b01%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: off topic - invite codes to 'riseup'
On Wednesday, May 10, 2017 at 12:40:33 AM UTC-5, none:qmane wrote: > toastflaming-re5jqeeqqe8avxtiumw...@public.gmane.org: > > On Tuesday, October 28, 2014 at 11:26:49 AM UTC-7, > > BM-2cU9wCijaFoqtF6...-A7g8B5KuuXnx/jn5l+7...@public.gmane.org wrote: > >> Dear qubes-users, > >> > >> I am long time qubes follower and user. I apologize in advance if anyone > >> feels this request is spam. > >> > >> I am looking for two invite codes needed to sign up to anonymous > >> riseup.net email service. > >> > >> I am hoping there are some qubes users who are riseup.net account > >> holders. > >> > >> Can anyone please send me a couple of invite codes that I might be able > >> to sign up? > >> > >> Thank you in advance. > > > > I would like one invite code, please. Thank you in advance. > > > > I have plenty, riseup, has gone to invite only system, per their last > newsleter fwiw, if I new how to use this newsgroup, I'd send you one, > or try to email me directly and I'll send a code , if your a still a > wanting a one , a man asks.. Could I get codes? Thanks in advance! -- 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/9bfeb23b-a718-43ba-9487-2e83c8e6c685%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qubes_dom0-root fsck failed with error code 4
Hello everyone. I'm running qubes 3.2 and I love it. Today I messed up and it's got my stomach in knots. I switched to my windows ssd for a legacy task that i have yet to migrate to linux. After I finished, i told the laptop to shut down. Then, perhaps too quickly, i closed the lid, flipped it over, pulled off the cover, took out the windows ssd and put in the qubes ssd. When i flipped it back over, to my horror i realized the laptop was still powered on. Immediately i fear i have either shorted the ssd or corrupted it. When I boot, it reached the password screen. After I enter my password it enters emergency mode. As instructed, i ran journalctl. The only errors are near the end, where it says: /dev/mapper/qubes_dom0-root contains a file system with errors, check forced. Then fsck failed with error code 4, and then a file system check failed on qubes_dom0-root. (See attached picture) I ran fsck /dev/mapper/qubes_dom0-root, but said no to every prompt, as I have no experience in this situation and I fear making things worse. But I did want to see what it had to say. Next I boot to the qubes install USB stick and choose Rescue a Qubes system. It reaches a point where Rescue asks me to choose: 1. find and mount the installed OS to /mnt/sysimage, 2. Mount it as read-only, 3. skip to shell, or 4. quit. I chose to continue. I enter my password when prompted, then it tells me that it has been mounted under /mnt/sysimage, and that I am able to mount it with chroot /mnt/sysimage. I ran chroot /mnt/sysimage, and it said: bash: /tmp/.bashrc: Structure needs cleaning I'm not sure what to do here but I assume I would be able to do something if I only knew what. It appears I have two potential courses of action: run the fsck, say yes to everything and hope for the best, or perhaps attempt something else from the chroot. However, I am new to linux. Usually I'm fairly cautious and don't get myself into these sorts of situations, but alas, here I am. I'm terrified of making things worse. I would rather wait to hear from the community on how to proceed. I would be grateful for any help in rescuing my data. I promise to do a full backup immediately after getting it running again. I am at your mercy. -- 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/2886d1f5-e63a-4b86-b8f2-ab42aff30dd9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: android on a vm
On Monday, 15 May 2017 03:05:07 UTC+10, mattiapa...@gmail.com wrote: > HI drew, i tried to install different versions of android and all of them > boot succesfully but when I try to reboot the hvm it stucks at the boot > screen saying "booting from hard disk." > So i googled something and I've found that maybe the problem could be the xen > hypervisor that must be changed with the nested virtualization adding two > line of code in the config file, but I didn't get where to find this file and > if is a vm's file or a qubes one I never changed anything, and mine works fine. I only got that issue when I didn't install correctly OR didn't set it to be bootable. I"ll find my resolution instructions and upload them later. -- 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/1e50c9c1-d683-486a-beae-ce04d4b1a330%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS
On Sunday, May 14, 2017 at 3:48:04 PM UTC-4, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > > > > What do you mean? Are you suggesting that qvm-backup has "more attack > vector" than an encrypted KeePassX (or whatever) database? Why? > No, I think it's actually the opposite. An attacker could feed you a > malformed database file, which you believe is your authentic database > file. If it's not authenticated, you won't be able to tell. When you > try to decrypt and open it with KeePassX, it could try to compromise > KeePassX. qvm-backup is designed to protect against this class of > attack. > I'm not sure what you mean. If an attacker has a copy of your > encrypted database and subsequently gets the key/passphrase to that > database, she can then decrypt the database regardless of what you > subsequently do. > > Are you saying that you would render the contents of the database > worthless by changing every password stored in that database? How > would you know to do this? Are you assuming that you'll somehow know > the instant your database has been compromised? What if the attacker > changes some or all of your passwords before you do? What if you have > persistent passwords (e.g., not for online accounts) that can't be > rendered useless in this way? > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > -BEGIN PGP SIGNATURE- > > iQIcBAEBCgAGBQJZGLRXAAoJENtN07w5UDAwmegP/imUHFRm0SadmiWdh6T71oWd > VaQt8TMrXoUeguysZEE3l0EwhWKbmET2KunXbkN5/RNfEz7wb9yIerNKnt5cTNMh > ko1ENAdNO9vWufJQyNSuZ+CScV/EL+tUG8626r28em1Rb2TknNk4COBb3pX0VRCC > RF3h7p+rSZufSy4xVuwVZRcllT94HhFTGpuvhzcB+f3FMmKjkTcYZLVL1gddiwcP > mEE1DAEGdsY5Y5eKl7xCAaiICvK2sSLWHTBGYZT3FZF6TSqLJ8iO92IoeMjPIbRS > +OShxw+ITr/g9oN+pSJ6con+mZk6xzrRC5ExZS9mRaYOLlXVx8LyC41cGVSxO0nb > KNoaMZqJ3nA8FtkfJ0Jo7786A2UBPYzSln4qzc8kqQ/23oa6Gevm9JckzixWLo3t > BnPN99fZ0zlspDcvkgPjoJhB3TPlUdvBbcHrWd5G93I/GIPCNp6yBvLAvoMyZcL5 > RdZ4yH+CB7BK1aInrHaHtKN68Bjep5ZTBXCmWVwIuXN2g82kip7uQ9qPAUtFvSqx > B4a/N1MPkVB80DFLRFHDdDQM0ChiEj3ewA3NPp2mk6ECJbnq0lxUeWGMU93pufuN > Dqx5EpopP1bVX8amLr8eYn+2C+eTAxgZIj+lC+dUg/kmqn/kjq7mzS3sCyxc41ni > iZbzihGynHg5/sZ31Oft > =nZE4 > -END PGP SIGNATURE- Well if they can do that to one file, couldn't they do that to alot more others if backing up the whole vm? I would think one file is alot easier to check. Since that whole vaultvm is only dedicated to that one file for me anyways, and I don't have custom configs or scripts in it. One cool thing I saw about paranoid mode is it take into account things in user directories that are not even user data to begin with. so ya I back up other vms that way especially templates, and especially vms with custom configs. or vms with just alot of data in alot of diff folders out of convenience. But for the vault I just do the single file. And so say if the database file is malware, what do you mean by qvm-backup would prevent it? And yes "rendering it useless by changing every password". We are talking of the times you suspect it, have a hunch, if you think you can never tell when you are compromised then what else is there to go on? and what else can be done? -- 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/b15a3edf-0d17-40a5-9a72-8f9761173f5b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS
On Sunday, May 14, 2017 at 10:38:37 PM UTC-4, cooloutac wrote: > On Sunday, May 14, 2017 at 3:48:04 PM UTC-4, Andrew David Wong wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > > > > > > What do you mean? Are you suggesting that qvm-backup has "more attack > > vector" than an encrypted KeePassX (or whatever) database? Why? > > No, I think it's actually the opposite. An attacker could feed you a > > malformed database file, which you believe is your authentic database > > file. If it's not authenticated, you won't be able to tell. When you > > try to decrypt and open it with KeePassX, it could try to compromise > > KeePassX. qvm-backup is designed to protect against this class of > > attack. > > I'm not sure what you mean. If an attacker has a copy of your > > encrypted database and subsequently gets the key/passphrase to that > > database, she can then decrypt the database regardless of what you > > subsequently do. > > > > Are you saying that you would render the contents of the database > > worthless by changing every password stored in that database? How > > would you know to do this? Are you assuming that you'll somehow know > > the instant your database has been compromised? What if the attacker > > changes some or all of your passwords before you do? What if you have > > persistent passwords (e.g., not for online accounts) that can't be > > rendered useless in this way? > > > > - -- > > Andrew David Wong (Axon) > > Community Manager, Qubes OS > > https://www.qubes-os.org > > -BEGIN PGP SIGNATURE- > > > > iQIcBAEBCgAGBQJZGLRXAAoJENtN07w5UDAwmegP/imUHFRm0SadmiWdh6T71oWd > > VaQt8TMrXoUeguysZEE3l0EwhWKbmET2KunXbkN5/RNfEz7wb9yIerNKnt5cTNMh > > ko1ENAdNO9vWufJQyNSuZ+CScV/EL+tUG8626r28em1Rb2TknNk4COBb3pX0VRCC > > RF3h7p+rSZufSy4xVuwVZRcllT94HhFTGpuvhzcB+f3FMmKjkTcYZLVL1gddiwcP > > mEE1DAEGdsY5Y5eKl7xCAaiICvK2sSLWHTBGYZT3FZF6TSqLJ8iO92IoeMjPIbRS > > +OShxw+ITr/g9oN+pSJ6con+mZk6xzrRC5ExZS9mRaYOLlXVx8LyC41cGVSxO0nb > > KNoaMZqJ3nA8FtkfJ0Jo7786A2UBPYzSln4qzc8kqQ/23oa6Gevm9JckzixWLo3t > > BnPN99fZ0zlspDcvkgPjoJhB3TPlUdvBbcHrWd5G93I/GIPCNp6yBvLAvoMyZcL5 > > RdZ4yH+CB7BK1aInrHaHtKN68Bjep5ZTBXCmWVwIuXN2g82kip7uQ9qPAUtFvSqx > > B4a/N1MPkVB80DFLRFHDdDQM0ChiEj3ewA3NPp2mk6ECJbnq0lxUeWGMU93pufuN > > Dqx5EpopP1bVX8amLr8eYn+2C+eTAxgZIj+lC+dUg/kmqn/kjq7mzS3sCyxc41ni > > iZbzihGynHg5/sZ31Oft > > =nZE4 > > -END PGP SIGNATURE- > > Well if they can do that to one file, couldn't they do that to alot more > others if backing up the whole vm? I would think one file is alot easier to > check. Since that whole vaultvm is only dedicated to that one file for me > anyways, and I don't have custom configs or scripts in it. > > One cool thing I saw about paranoid mode is it take into account things in > user directories that are not even user data to begin with. so ya I back up > other vms that way especially templates, and especially vms with custom > configs. or vms with just alot of data in alot of diff folders out of > convenience. > > But for the vault I just do the single file. > > And so say if the database file is malware, what do you mean by qvm-backup > would prevent it? > > And yes "rendering it useless by changing every password". We are talking of > the times you suspect it, have a hunch, if you think you can never tell when > you are compromised then what else is there to go on? and what else can be > done? by a hunch I mean like noticing weird anomalies, freezes, crashes, mouse issues, lag, or just anything really, timing and sequence of events. after my account gets hacked do I still just say it could just be a random bug cause I have no proof? if we really can't notice anything suspicious in even with live realtime network traffic, system logs, or file integrity logs, then what else are you supposed to do. Just already assume its compromised. -- 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/01ae4ab6-c8dd-4555-8c5c-73abc9cb6cee%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Accessing Android phone photos
On Sunday, May 14, 2017 at 1:36:32 AM UTC-4, Vít Šesták wrote: > Maybe the phone resets its USB connection at that point (as it was unplugged > and plugged again), so it appears in sys-usb again. Do you see it here? > > Workarounds: > > * Ideally, there would be a way to tell sys-usb not to communicate to the > device when it reconnects and to somehow reconnect it as soon as it > reappears. AFAIK, there is currently no such option. > * You might try to assing it again, but I am unsure if it will work. > * Can you set your phone to allow it without asking? This might prevent the > reconnects… > > Regards, > Vít Šesták 'v6ak' i you idle it for a couple minutes probably whenever your phoen screen lock go on, you have to hit allow on the phone again. everytime you try to access the drive keep screen unlocked and be ready to hit allow on the phone. -- 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/5f712430-7d91-49bf-ba52-e365911d9e93%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Laptop with discrete graphics card, any chance it'll work?
On Monday, 15 May 2017 03:12:18 UTC+8, tai...@gmx.com wrote: > I would get a laptop with AMD graphics instead, or get an older model > like the T430 or W530 (and you can install open source init coreboot on > that) Thanks. I'm convinced. I'll go for a laptop with Radeon chipset. I've been looking around for one, but I can't really find any machines that are appealing. The only ones I've been able to find are huge things that seems incredibly uncomfortable to use and carry around. I also haven't been able to find a single laptop with the R9 chipset. Does anyone have a suggestion on a reasonably light laptop (2 kg or so) with a modern CPU and Radeon chipset? Something similar to the XPS 15. Price is not really an issue. Does anything like that even exist? -- 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/740fedee-9c37-4c7e-b0ad-f1a885679c72%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-05-14 21:38, cooloutac wrote: > On Sunday, May 14, 2017 at 3:48:04 PM UTC-4, Andrew David Wong > wrote: > > What do you mean? Are you suggesting that qvm-backup has "more > attack vector" than an encrypted KeePassX (or whatever) database? > Why? No, I think it's actually the opposite. An attacker could feed > you a malformed database file, which you believe is your authentic > database file. If it's not authenticated, you won't be able to > tell. When you try to decrypt and open it with KeePassX, it could > try to compromise KeePassX. qvm-backup is designed to protect > against this class of attack. I'm not sure what you mean. If an > attacker has a copy of your encrypted database and subsequently > gets the key/passphrase to that database, she can then decrypt the > database regardless of what you subsequently do. > > Are you saying that you would render the contents of the database > worthless by changing every password stored in that database? How > would you know to do this? Are you assuming that you'll somehow > know the instant your database has been compromised? What if the > attacker changes some or all of your passwords before you do? What > if you have persistent passwords (e.g., not for online accounts) > that can't be rendered useless in this way? > > > Well if they can do that to one file, couldn't they do that to > alot more others if backing up the whole vm? I would think one file > is alot easier to check. Since that whole vaultvm is only dedicated > to that one file for me anyways, and I don't have custom configs or > scripts in it. > No. With qvm-backup-restore, the entire backup blob is checked for integrity and authenticity. That check will fail if any bit in the blob has changed. Since the blob is encrypted, an attacker won't be able to tell what individual files are in it, unless you divulge that information in some other way. > One cool thing I saw about paranoid mode is it take into account > things in user directories that are not even user data to begin > with. so ya I back up other vms that way especially templates, and > especially vms with custom configs. or vms with just alot of data > in alot of diff folders out of convenience. > > But for the vault I just do the single file. > > And so say if the database file is malware, what do you mean by > qvm-backup would prevent it? > Suppose you take your encrypted database file and store it somewhere (e.g., cloud storage, HDD in a safe deposit box). Suppose that an attacker secretly replaces that file with a malicious one without your knowledge. The next time you decrypt that database file, it silently compromises your client or VM and leaks your passphrases through side channels or does other nasty things. If you had instead backed up the entire VM with qvm-backup, you would immediately know, upon trying to restore from the backup, that it was not the same trusted file that you had originally created, since Qubes would inform you that the integrity and authenticity check had failed when you entered your passphrase. Now, if your password manager also uses authenticated encryption for its database files, then that's fine, but as far as I know, most don't. > And yes "rendering it useless by changing every password". We are > talking of the times you suspect it, have a hunch, if you think you > can never tell when you are compromised then what else is there to > go on? There's nothing wrong with acting on a hunch. In some cases, it may be obvious that a VM or whole system has been compromised, but there's no way to know for certain that a VM or whole system has *not* been compromised. > and what else can be done? > Use Qubes OS. Compartmentalize. Use Paranoid Mode. :) - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJZGRvVAAoJENtN07w5UDAwHAAQALd0vAijgbKELXG+Zc/lHT/Y 0MjYwfzxhjEzxD/nkqgVRjhX8Pjvwxq7LZGtSE0D6TlLl6VRM6OUwjsc2JCD7iSE /HIij8h/D89wgIuWLXBD394sBuGvLOjoHsaDbSU/GHfN16r88YKJ6L1YDe5XPiwL 0AuM8zvVVcPshNa7QH7fnnWo/VlA9wM2zr6NfKIclEyW1Ty555SXztlG03sQIrDD 1J4+7/NM9zHUvaWtgoy2PcFEPbEiXcL5IqoWUeWxDQhG5fWFuUcYDK5L3dheN43A B2YYwKK60DpH1/qIXjslpz6jYlV1KSAUaibI1GNQcXkj9HaQ6qHihUUCucYUbrIY pfMAmtPxOPpReA0HLRT0EurLsknVZ4dj/Va0oUbbL12ZbIsZM6qSoGHA2Uc/8I1+ wQKWOaeSeiluARGwQMfHDOEoM9D6JzJ7LqRhCrV6jAuwMeWiFdeBd+6l/wtN8e9g UNqoKqK0JOJMJXiQct9zrZ0vyeqGloyW7X/BmytAM/MTznsa5fA+lzG5gx7/IWrZ BFarprX2R2rIrFkQoEn3LO0DkfjQs+7QKpKXLuvl3lk11Slib13Ah2qLfcV7dMg2 8PpHxVkmuLMfbHwCDFZZSs1K3jZ+c9J0wZZF46bqWqt5DeZi9F+JkBQ53/V2a3dW 52CXFlG7RHmJXxVujHjT =Z70t -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
[qubes-users] Re: qubes_dom0-root fsck failed with error code 4
I went ahead and did fsck, saying yes to all prompts. It went a little crazy for a while, then finished. The shutdown command doesnt exist, so i lowered it off. The next boot progressed till it sat at a umts something or other. Another poweroff, and the next boot finished. I'm logged in now, but no VMs will start. -- 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/1b96b339-401c-49cc-ac92-addd6016729f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: qubes_dom0-root fsck failed with error code 4
The Guest log for the VMs say the filesystems are read-only. The fedora template also doesnt boot. I've rebooted once again to the usb install stick and try to rescue. Again I chose option 1 to mount the partition, and when i run chmod /mnt/sysimage, i dont get any errors. >From here I woud like to run a checkdisk or something like in windows. Am I on >the right track? If I coud just get these VMs to boot I could get my data off of them and do a full reinstall. Any help would be appreciated. -- 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/8ccc7918-4b88-41ca-865d-5369bca4c78b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: HCL - Asus Laptop F556UA-UH71 i7-7500U Intel HD 620
On 04/29/2017 05:36 PM, 'Mike Freemon' via qubes-users wrote: Hello, I'm a big fan of Qubes. Keep up the excellent work. My initial contribution to the cause is this HCL. Qubes is working great on the titular laptop, but there were some challenges to overcome during installation. 1. UEFI. Installing from USB. I found that I had to disable CSM and select boot partition 1 to get the installation media to boot. 2. Touchpad. The touchpad was not working. To install with a USB mouse, I set qubes.InputMouse to pass mouse events to Dom0. Of course, the USB mouse only works when sys-usb is running. 3. Wireless. I had to get the wireless working by using nmcli commands (e.g. nmcli device wifi connect ). I should add that some of this was when I was trying to install via text only, which requires a little more background info: My initial install attempts were from legacy booting, which failed to launch the graphical interface. I tried to continue with the installation via the text interface, which I never did get working. That's when I went back to step 1 and got it working via UEFI / partition 1 with CSM disabled. 4. Display Resolution. The display was only 800x600. The short version: The display issues were caused by using a kernel that is "too old" (for this hardware). This hardware requires kernel 4.8.12 (to be more precise, all I can say at the moment is that the minimum kernel version for this hardware is > 4.4.55 and <= 4.8.12). Kernel 4.8.12 is only available from the unstable repository, so I had to get Qubes installed in a "degraded" way before I could issue the magic command: qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel kernel-qubes-vm A quick follow up on this hardware. I found that the wireless NIC failed to work after suspend/resume. The hardware is: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter (rev 31) There are several reports of this hardware having problems with suspend/resume. https://bugs.archlinux.org/task/53389?project=5&cat= https://forums.kali.org/showthread.php?31444-No-wireless-connection-after-sleep-suspend http://jfcarter.net/~jimc/hardware/acer-e5-573g/setup.shtml On this last one, the following is mentioned: "Update: S3 becomes reliable if you leave it asleep or awake for at least 5 mins between state transitions." This is potentially interesting (as a diagnostic test, not as a solution). I have not confirmed this myself. As will come as no surprise to readers of this list, unloading/reloading the kernel module did work around the problem. Described here: https://www.qubes-os.org/doc/wireless-troubleshooting/ In my case, the drivers to include in suspend-module-blacklist are: ath10k_pci ath10k_core ath Note: I also tried disabling VT-d as a test, which did not change/fix anything in my case. -- 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/63868f45-e4ef-894a-e46f-3b3176f0e8b2%40zoho.com. For more options, visit https://groups.google.com/d/optout.
