Re: [qubes-devel] Re: [qubes-users] Re: Request for feedback: 4.9 Kernel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Jun 15, 2017 at 09:53:11PM +0200, Zrubi wrote: > On 06/15/2017 06:34 PM, Reg Tiangha wrote: > > > Curious: For those apps that exhibit that behavior, are they > > running on Debian 9 or Fedora 25 templates? > > Nope. > Fedora 24 mainly, and Debian 8 > The later is only for sys-net, so all my taskbar icons coming from a > F24 based template. Make sure you have up to date qubes-gui-agent (qubes-gui-vm). There were some issues recently affecting integrity of window content affecting F24 (or F25 - depending on gui-agent version ;) ). > > Since it works fine in Debian 8 (I haven't tested much with any > > Fedoras), I'm wondering if it's less a kernel issue and more of an > > issue with newer X or how Qubes integrates with newer X (but I > > guess if it works properly on 4.4, it may be a combination of the > > three; don't know how to fix it though). > > Maybe it is a know issue, but: > online netvm change on a disposable VM is also broken on the latest > 4.9 VM kernel. (Qubes Manager shows it is changed, but not working in > practice) Can you provide more details (and even better: create an issue on github)? I've just tried and cannot reproduce. I've tried two scenarios: 1. fedora-25-dvm with netvm=sys-firewall, then new DispVM switched to another netvm (sys-whonix) - it works 2. fedora-25-dvm with netvm=none, then new DispVM switched to sys-firewall - it works After changing netvm for fedora-25-dvm you need to regenerate DispVM savefile. All of this using 4.9 kernel (some .28, some .31). > > I can't play around with this until later today, but in the > > meantime, what graphics hardware are you running, Zrubi? And which > > version of 4.4 are you running where things work fine? And finally > > if you can, if it's an Intel card, can you try booting with this > > kernel option to see if it makes a difference? > > > > i915.preliminary_hw_support=0 > > I believe this setting will not affect this chipset. But will try if I > have a chance. (This is my only Qubes Laptop atm and using it for > production) > > HW details: > > Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz > Intel Corporation Broadwell-U Host Bridge -OPI [8086:1604] (rev 09) > Intel Corporation HD Graphics 5500 [8086:1616] (rev 09) (prog-if 00 > > SW versions: > Qubes 3.2 > xen: 4.6.5 > kernel: 4.4.62-12 I've seen some graphics issues (different than yours) on Broadwell-based hardware, on 4.9 kernel. Adding iommu=no-igfx to Xen cmdline helped. See here: https://github.com/QubesOS/qubes-issues/issues/2836 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJZRurmAAoJENuP0xzK19csFNoH/1DYra+sHUObaQnIIxCWG+sv 7ET5hQmwEyT+JazddANq/JHDlwIbqrIc+f4FE/IA59kkruZiprmvWAh7mEd87zEz 9eh5cx5P0KOhSxbf1FQ5S4109/8kTUXm2rfGhJa0OQduvKk97zJ9AoiC8KdDMb4U Xdh9EcYYr1kHgTKFWE17qi0i6urXYvl52pRUeLB6Qp0uSXL/zqqOFylSSzWdVq2c hHQHmxrNGTd8y54M2ME3QzD28mzPdhdKSiy30mptFMr1f2cNad3mHl6/DI5PNxgA QZW/I0Ljt6SzDAA/HJRjjK2+6fCafuuedCuqXYl/Jq5qRA5zquSr2OxZZOslUwY= =giIk -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20170618210438.GM1268%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
On 06/18/2017 05:51 PM, Rusty Bird wrote: > Rusty Bird: >> Patrik Hagara: >>> Single-use key file code committed > >> Whee, I finally get it... Seeing how it all fits together, it looks >> really cool! > >> What do you think about making replay protection a self-contained >> secret? If we'd change it from a counter (shared between the combined >> counter+keyfile secret and NVRAM) to a per-boot random string stored >> in a separate secret.fresh[.sealed] file, and stored in NVRAM _as a >> hash_ -- then AFAICT the attacker still wouldn't be able to malleate >> the secret in any meaningful way, and: > >> - secret.fresh.sealed (the first to be unsealed) could be used to >> replay-protect all types of AEM secrets, not just keyfiles > >> - If secret.fresh.sealed is in fact stale, the keyfile would never >> have to be unsealed into memory, where it's susceptible to a cold >> boot attack (probably even if the tmpfs file is shredded, due to >> buffers) > >> - It seems like this approach should simplify the implementation? No >> concat/split code, fewer special cases (e.g. all AEM setups would >> have the same always-reseal workflow) > > Hmm, replay protection would be incompatible with the use case in > which a backup AEM stick is stashed away somewhere. So it probably > shouldn't be enabled in non-MFA setups after all, or at least not > unconditionally. Anti-replay secrets could be compatible even with backup AEM sticks, just by having separate secrets for each AEM device. However, always resealing would not work for read-only media. For cold boot attacks, a good solution would be to encrypt the whole memory using eg. TRESOR (storing encryption key in CPU debug registers), with no perceptible performance penalty on Qubes 4.0 compatible CPUs, as most/all Intel processors with VT-d also have AES-NI. Not sure whether encrypting RAM from Linux would be enough or whether we would need to implement the encryption in earlier boot stage (tboot or Xen). I guess your last point is valid, we can seal the actual secrets (txt/png/keyfile) just once and always reseal only the "freshness" token. I'll have to think more about this, but so far I didn't find any obvious flaw with this approach. As for the DMA attack mentioned in your later e-mail, shouldn't the IOMMU (which is required for Qubes 4.0) automatically protect against that (as it gets activated by Xen)? Cheers, Patrik -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/18f570e7-10c4-e2f8-bcbd-89aac4834cdf%40gmail.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Patrik Hagara: > The initramfs would, upon next boot, read both the sealed LUKS key file > (unsealing it, along with stored counter value) and the publicly > readable counter value from TPM -- and, assuming the values match, > continue booting. An attacker cannot circumvent this check -- changing > the code will result in different PCR hash and thus the key file failing > to unseal. One possible attack would be to patch out this check in memory as soon as the kernel has started up, i.e. after SINIT has already measured the initramfs, using DMA from a malicious PCI (ExpressCard, Thunderbolt) device. Similar to TRESOR-HUNT [1], in spirit. But I don't think this invalidates your implementation, which at least requires the attacker to have such a device at hand. Rusty 1. http://old.iseclab.org/papers/acsac2012dma.pdf -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJZRtO+XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfJgYP/3KQ3OkTteHGTqMX7Rj7NLhI 8P6s6xHSXOkd2jTK9Ss4bT3aCSsoYPUcOXrUSRf/wYhPCuIqP9OXCpOxyzC2V567 VnTzjCEEt27W/F43skNRygRVIIfkw7OBFNpHPgj9HkeaDprM4csI3mQ0wElIMx7Y cL+f0ymSFTJCL5G4/sfhzixVmL+yjDbZYjDoIaiI8no563t6DVvz2UdjpF5vEpX2 gyj1InqTJ0aiHrGPDTGnVQbZ5SbIFCcAW5gIL50cW7RVbw3xHGo5lgR3hHtx0hn/ 6fvhrFCJIxhJCba1NmDQ5uz6Ybjr1AU2Dx4fr+SQ/TKtkSCaZ1cu6vpg+mCjJxQb v8ZLRsQDkcE8k9diLCXyQcXVkLBKdX+xJMnem0+y2VEdgd86lr8HK45uptrtwsWe aepeyHZlbem4qBZA4pzIdAwHPfbZzH3oQCcGRkdspBpS7Ls2BMUf38HJklM+MVPO fMFVUM2peEpmpzsdumJcS3RlF/VpQT5fzZwbPxhQMRmJnJyvfRvh+9BqRDRus0SC Lifp8k3ldhzh3U+VWcRH5N64wDUaEIpBwbrj+SNuHwVYWggsY1aDFNIwdyFCCJne fbc+ovHRKSrzC2xcWVsXtDQnxieHqX9oXWd7BGh/CfUcddXcHQ/L2o5qi4FTnX5p qfkOdzlliBvDp0UPVQQg =wHwZ -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20170618192347.GB8291%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] AEM: Should we drop .png support?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Marek Marczykowski-Górecki: > I think PNG support is a nice half-measure against shoulder surfing - > details on the image are harder to copy/remember (or even photograph > with a small camera), than some text. You're right, it is better. I hadn't considered that the user can manually clear the image from screen as soon as they've recognized it, simply by pressing Esc to switch to text mode. > When we get some better alternative, we can drop PNG. Sounds good. Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJZRtGEXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfltsP/3prk/o8c3k/5F0E6pOVuzFb JIrfc2Vct0Ai/LbUX9OlwNGKBlxZbUv/KoxrxPWnOXT5YUEmXRBOkKneZsOeGYk1 OleLQ4A2SJaq5+e4WTRvSY6nk+i9LswMMvTkWCi/2zNo08HMGdmHUpE3vmNkp+uJ 5OwCmR4pIbQ4hrQN+MWJPHXtz6NMmvksoB8OgSBEIULqtU0Hp5kijxW416kNi86q sknnfk/kj7mnanQW9IRkmkiQ740RJP/1lQ93khrBdF2H+4Ue0g2PvxkMohVNWgGm kfkVYjAeu3zVnLpsXsbtLu9VpMQ+xNFXY32rfm9kzg+X65Pd3GfTEj+IqdcV04ST MhQ3KSuoZlyX6Tfk4jmd4acBHrWgSEwSB8NlsgK3qWxMn+NuAfEilQm4awYtwedw ItpUTUcqDFg02nMfyfY3kvhnm2JjeIEVc4VrrB1452Tg/5exu+j1DyqLLHFd8WvY KdmN0Gddfe70JZYB1fmutWF7OCY4FYMBi177avstVeAqlhC6Aa9UNJtSu88jrmdm fnDpS3LS4anrjj3+OxLxJZJeJ3SNO6M16rhEIf81Y6FGzy+X3TOECBDsKGdycwNR 0FZM19X+8+8koQEUPt8ZxBZC6AphTpX1GNKXBzrWTovzflNUDiNklZm6DQU0rDhc nR+E4brBA+9dfqPdkMg/ =TDgE -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20170618191620.GA8291%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] AEM: Should we drop .png support?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Jun 16, 2017 at 01:47:25PM +, Rusty Bird wrote: > Hi everyone, > > What do you think about getting rid [1] of .png image secret support in > the next major version of Anti Evil Maid? This would offset some of the > increase in complexity incurred by the upcoming TOTP/keyfile support, in > addition to other benefits: > > - Considering that AEM is a security oriented feature, it's kind of bad > to implicitly encourage the user to copy a complex image format from > some VM to dom0 - where it will be parsed during boot. (It would be > possible to build something [2] secure using the qubes.GetImageRGBA > RPC service, but I don't know if anyone's particularly interested in > working on that.) > > - .png support is hacky and weird: We show text secrets in the current > dialog, but images appear in the *next* dialog. And text secrets are > cleared from the screen as soon as possible, whereas image secrets > stay visible until Plymouth finishes. > > For users who prefer the more visual approach, we could tweak the > Plymouth theme to use a monospace font for text secrets. That should > make ASCII art a viable replacement for conventional images. I think PNG support is a nice half-measure against shoulder surfing - details on the image are harder to copy/remember (or even photograph with a small camera), than some text. When we get some better alternative, we can drop PNG. > 1. > https://github.com/rustybird/qubes-antievilmaid/commit/4e45af289d0e651a380f3182cb07901a3002905f > > 2. Similar to the WIP dom0 wallpaper service: >https://github.com/QubesOS/qubes-issues/issues/215 > - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJZRszfAAoJENuP0xzK19csNPQIAI8ihNjr2yQsvWqJNdW0IjDa Qy5JeFu89Xu0/YzqiyRb887q2RgnKBc+jwdQO+KypuFeLNVXvNvLOfwZA9Tx3NGW zN3bqNmTdS9rNYo5qDvqgsdxNuGcHpfJlHwkIl97EulZZS1Y5jG+FT2p2U/x75GK 3X7kJmuPPCwSEhUD14j3URlsNWDVJi9MQST4q+XgXvmUOhtSr1h5TkKrWDyR3VXD Dj1O2CXwVpyClf/IxU5mt6o60iL6cCDzvSFhMOEsaHzKZxkXDXe1Y7DdVIv7GU65 35rWmr6p842H6L+JeFXuUg8eLSsCfWuPof72BWveVLNH7pNnTxZnkQyIX8xwxmc= =Lp1V -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20170618185630.GA8758%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Routing Qubes master audio to a VM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jun 18, 2017 at 04:17:02PM +0100, Matt McCutchen wrote: > I have a Bluetooth headset that I'd like to use with multiple VMs. > Assigning the Bluetooth controller to each VM (at either the PCI or USB > level) when I want to use that VM isn't an ideal solution because each > VM needs a pairing key to secure the Bluetooth connection to the > headset. If I copy the same pairing key to all of the VMs, then an > attacker within Bluetooth range who had access to one VM could > intercept the audio connection when I'm using the headset with a > different VM. It might work to have each VM use a different Bluetooth > device address and share a separate pairing key with the headset, but > I'm liable to reach the headset's limit on number of paired devices. > > So I'd like to try to implement a better solution: assigning the > Bluetooth controller to one VM (call it the "AudioVM") and routing the > Qubes master audio source and sink to that VM. I can think of two > basic ways to do this: > > 1. Run all the pacat-simple-vchan processes in the AudioVM instead of > Dom0. Will it just work for client VMs to specify the domain ID of the > AudioVM when creating the vchan, or are there restrictions? A new > protocol would be needed for Dom0 to control the lifecycle and the > recording-allowed state of the pacat-simple-vchan processes. > > 2. Run one more module-vchan-sink / pacat-simple-vchan pair (but > without recording restrictions) from Dom0 to the AudioVM. Might > increase latency. > > Are there any issues I should be aware of before starting > implementation? If I'm just doing this for myself, I'm inclined to try > #2 first because it should require less new code and high latency isn't > a big problem for me (as long as it's stable, which it has been so far: > I play StepMania!). But if Qubes maintainers are interested in having > the feature upstream and prefer #1, I'll do that instead. #1 is definitely better for latency, but also from architecture point of view - ultimately it will allow to get rid of one more thing out of dom0 (either to dedicated AudioVM, or to GUI VM). Technically, you need to pass domain ID to vchan initialization in module-vchan-sink (gui-agent-linux/pulse/module-vchan-sink.c). I think you should use Qubes DB to let VMs know this ID (and set it during VM startup in dom0, based on some VM property). Recording control is currently implemented over dbus (session bus). It's easy to expose it over qrexec - just add one/two qrexec services with appropriate dbus-send commands. For good UX, there should be shortcut to start audio mixer there and also some audio applet. And probably appropriate handling of volume control keys (up/down/mute). All over qrexec. Some references: https://github.com/QubesOS/qubes-issues/issues/1590 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJZRszGAAoJENuP0xzK19csNpUH/i12ttPJCp5ltfSV1Pb/0e0h W35OSvCl0DROF7ewLOz5++flQP+Tnn+ppcc3Okd/QOqPakvSYCYrx9XM9PY1IFAV oP2y+yURZ0XA2OGO9HhE+1IBTwJgaYAQFGp68iBWr7FPaNPSm5NhGK8adWT8nK+9 zsskhqAKEFfqVTquqRcdsT4aMfZyCtRf5qloKkRRzatFHC7EQlt2RRMx5wpMY+CS 3GQZXkRtDt/A7qF3KElCpokEEQxoXg01WYcmDa638QtHR5XaQpcmGyIpHGABUqnn Fzdl9rcuNbJcBXbJ5S+XpQQ0wZ+Hlnm+6Hy10ouuzqmXySS+TorYBpGSbbkGgFQ= =+TRr -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20170618185606.GL1268%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Routing Qubes master audio to a VM
> If I copy the same pairing key to all of the VMs, then an > attacker within Bluetooth range who had access to one VM could > intercept the audio connection when I'm using the headset with a > different VM. If an attacker is within Bluetooth range he can probably use a microphone and listen to you without "intercepting" anything. bluetooth has a very short range. if there is a simple solution good; but i wouldn't worry about such attack. or am i wrong? -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/a3090272-3438-d62e-be83-e8b8d8612525%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: 3.2.1 should be released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Jun 15, 2017 at 05:39:08PM -0600, Reg Tiangha wrote: > On 06/15/2017 05:12 PM, pixel fairy wrote: > > On Thursday, June 15, 2017 at 11:50:31 AM UTC-7, Reg Tiangha wrote: > > > > > > We're still stuck with FC23 in dom0 though, although you could > > attempt > > to build an ISO that uses FC24 or FC25 in dom0; some people have. > > It's > > unsupported though and you're on your own when it comes to compiling > > Qubes updates for dom0 afterwards. > > > > > > why stuck with fc23? thought marek had built fc25, but was having > > trouble with fc26 > > -- > > > Will they update dom0 in R3.2 to FC25? It'd be great if they did, but I > was under the impression that FC25 in dom0 was an R4.0 only thing. If > I'm wrong, that'd be fantastic. R3.2 will stay at fc23 in dom0. There may be fc26 template, but there are issues (build failures of Xen, because of much newer gcc). Dom0 in Qubes 4.0 is based on fc25. As for Qubes 3.2.1 - exactly as Reg said - it's blocked on 4.9 kernel testing. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJZRrWmAAoJENuP0xzK19csjssH/3U83Hi4Bud4q7dPFw+6/y6B KkLmTPCcJzrCj7rYHErtxG1DjSJKGdZtFcSMJXUJYuZCiIzosNtwqnkhFcLcVvCJ 8vFJST7NNBUI75xLynXQ4XlxPQyknt+pjjiAHDUBopuXcubhhFgoEiVtu766zivf 7er8zHJpQsaZH5zasu9K3J03B8M/6wN4jeu7OhHTV1HGFUVtXFQx50KYfpFZRHng n/FTaH/9OlFG/hghA9zBdux2iLj//uF1hj+YipUedDAYzeEyNFmnhHDuEEG8L4wv UKRaOe1Y8YdMp5Bp2aNZIb1ix9SMaXrGpJQXemUZ3/8RRR6cqa1um0hrROTlNtA= =qx0U -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20170618171726.GC3857%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Debian 9 Stretch and GPU support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jun 18, 2017 at 02:02:22AM -0700, stevenwinderl...@gmail.com wrote: > https://www.debian.org/releases/stretch/releasenotes.en.html > > Will you update Debian Templates in QubesOS 3.2 to Debian 9 and also have > this available in QubesOS 4? Yes, there will be Debian 9 template for both Qubes 3.2 and Qubes 4.0. Before the pre-built template is available, you can upgrade existing Debian 8 to Debian 9, see here: https://www.qubes-os.org/doc/templates/debian/ > Also is there any ETA when you will support full GPU support and > passthrough for VMs in Qubes? This could especially be handy for Windows > VMs and > Gamers obviously :) I'm afraid the only answer I can provide is "not soon"... - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJZRrOMAAoJENuP0xzK19csQ74H/0ShlPg9I/BFlj4kwcUp+5eh /F4esaseu+3IyDTi1aEXUBQWsWP8qI3ob+1WvOGsW1OLV2rSNqGU1HBWC2mLRJN7 3uNS6xT9rmxAQO17UcjOMu19UHZ72aAW9Ri9G9Q+IXRNqeuaaESrCfJ51kDBh0rO tuljFPADCQAtLCHA49KbqUrkPVRbc8d3zgqywAiXiBrZzrpIum/iaf3DhV97y1mV QHKQnZWZq9vmjrgfwFWcPfw97tldvISR+hiBSD187xF3vNZcXWdFIZsQlqRcfbBf NNISX7G8hW2FMryw24nUqcQICA857VHK0glyKBzJyS+Dgo2wBoWIE0FP31Lkjco= =nU9q -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20170618170828.GI1268%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Rusty Bird: > Patrik Hagara: > > Single-use key file code committed > > Whee, I finally get it... Seeing how it all fits together, it looks > really cool! > > What do you think about making replay protection a self-contained > secret? If we'd change it from a counter (shared between the combined > counter+keyfile secret and NVRAM) to a per-boot random string stored > in a separate secret.fresh[.sealed] file, and stored in NVRAM _as a > hash_ -- then AFAICT the attacker still wouldn't be able to malleate > the secret in any meaningful way, and: > > - secret.fresh.sealed (the first to be unsealed) could be used to > replay-protect all types of AEM secrets, not just keyfiles > > - If secret.fresh.sealed is in fact stale, the keyfile would never > have to be unsealed into memory, where it's susceptible to a cold > boot attack (probably even if the tmpfs file is shredded, due to > buffers) > > - It seems like this approach should simplify the implementation? No > concat/split code, fewer special cases (e.g. all AEM setups would > have the same always-reseal workflow) Hmm, replay protection would be incompatible with the use case in which a backup AEM stick is stashed away somewhere. So it probably shouldn't be enabled in non-MFA setups after all, or at least not unconditionally. Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJZRqF6XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrflCQP/i4NBM8yXNzZ9jLrMxpbwiUz nw3zWkm/NrjTEE6lWob7dFS8CN8lMkapt3x7fx90uky0XGcsNVSfghxcF+yjaOuo Ni9wuvkfCAYDfrcTaUHZV2M21sHlxIM+dagmZqMPFlJt9LTu6Ju0P+nExQvZ7C0w ZM7h2MFX7X89g+ESo5j/ZQQwghXh9NTOjpxC4UUTfsWwyCLROmrvmbvpWBwUa7m3 nWAfFL1qUnIENtrlHvq/fKmkIVpVRHmU8Gbhy1u5wH23aTAk5XqGBriw2HM7WdML oS37e15uymf4TxqSl9Ehwc9gHdLHrWVaEgImrIc1buEQZppSl3iQy98YGP3FfpWQ qEwrURqHc45r4gfz2VwRo6XTJ18tgL7dGr+JfQJIY3pwQO4SSdL9ZPSPIITdlR9C zoe33FCqdg1HlcW+PLAVV8MV3KKaSilxI1wGRinhYKQUpKvnOnmUQRjMBZNY2o+9 xqFsLIfglhUzE4u9noE1IREudWSB+hBaFRncAdg7SgZOvV9oEJsVYA+rVdF9reBA 1oUo37qShLMfD9Cilos/hgvO5hJ+41VND3GFyhrhoQ6b/25PmnhVIEAWXLtPWj7V mdaHVqYaHK/p/eDfeHCiPBHMAGrFk+97cnD2wW+Ds7vQGufvxDbiK73zSFK+sMCq VyqfZcTnHUygcP26Dm+U =rDb3 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20170618155122.GA7654%40mutt. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Routing Qubes master audio to a VM
I have a Bluetooth headset that I'd like to use with multiple VMs. Assigning the Bluetooth controller to each VM (at either the PCI or USB level) when I want to use that VM isn't an ideal solution because each VM needs a pairing key to secure the Bluetooth connection to the headset. If I copy the same pairing key to all of the VMs, then an attacker within Bluetooth range who had access to one VM could intercept the audio connection when I'm using the headset with a different VM. It might work to have each VM use a different Bluetooth device address and share a separate pairing key with the headset, but I'm liable to reach the headset's limit on number of paired devices. So I'd like to try to implement a better solution: assigning the Bluetooth controller to one VM (call it the "AudioVM") and routing the Qubes master audio source and sink to that VM. I can think of two basic ways to do this: 1. Run all the pacat-simple-vchan processes in the AudioVM instead of Dom0. Will it just work for client VMs to specify the domain ID of the AudioVM when creating the vchan, or are there restrictions? A new protocol would be needed for Dom0 to control the lifecycle and the recording-allowed state of the pacat-simple-vchan processes. 2. Run one more module-vchan-sink / pacat-simple-vchan pair (but without recording restrictions) from Dom0 to the AudioVM. Might increase latency. Are there any issues I should be aware of before starting implementation? If I'm just doing this for myself, I'm inclined to try #2 first because it should require less new code and high latency isn't a big problem for me (as long as it's stable, which it has been so far: I play StepMania!). But if Qubes maintainers are interested in having the feature upstream and prefer #1, I'll do that instead. I found a previous thread about roughly the same problem. The author proposed approach #2, but apparently it wasn't implemented. https://groups.google.com/d/topic/qubes-users/GrN5OhCwttw/discussion Thanks, Matt -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/1497799022.4151.2.camel%40mattmccutchen.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Patrik Hagara: > Single-use key file code committed Whee, I finally get it... Seeing how it all fits together, it looks really cool! What do you think about making replay protection a self-contained secret? If we'd change it from a counter (shared between the combined counter+keyfile secret and NVRAM) to a per-boot random string stored in a separate secret.fresh[.sealed] file, and stored in NVRAM _as a hash_ -- then AFAICT the attacker still wouldn't be able to malleate the secret in any meaningful way, and: - - secret.fresh.sealed (the first to be unsealed) could be used to replay-protect all types of AEM secrets, not just keyfiles - - If secret.fresh.sealed is in fact stale, the keyfile would never have to be unsealed into memory, where it's susceptible to a cold boot attack (probably even if the tmpfs file is shredded, due to buffers) - - It seems like this approach should simplify the implementation? No concat/split code, fewer special cases (e.g. all AEM setups would have the same always-reseal workflow) Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJZRpsMXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfwXMP/3e3eas+5uDtq98w5A+fwW+W A56dVp/e1e8TqsumtHxlmo3rZ2IF6nfvFwjwcKAvQ200KTj0nBvBposXXM5GD2i0 hskpLzEkq2Dapbgnyqd9RWUiQ57ieOWg5qXJmS61q4q9njTgSbIhtnyxgFczqmAb nwc6q/H2eAia4hE0A40aMKOby8T89l4VYo0Czipz8zEZqGtnRRI2yCyhDZLu+eR8 raV9kggH6g/oJjmr+jTnOx1SHUFSVieOns4RfzoaTxV0y86TPknc5QG80/IheP3d AqvEUd6P4MYdngZoL7Txwh0VNE4WwK8qn64bPX27jEJIXZuWxn01P9rQee2dYAJZ SD4JG5/NtYBCopFmZJ2zZ54PjfreO/SoUrlk6CB2ZKF/JLc91qi/2xsrYZIwSPCj Bdr84aUhb3T5I9kBaLM6eX19CZeqFa2bzSfSa1IedS5lqUcGnJddn2zHn3PSjUBp 9g1AVEkF9fhHjPvdBHmHYiyKRMDLW7+FzdCSNNt2vocfGNJu4fyNdGl2AYanuUrk BjhnP+lotYtAUzIwH+l+SX9HhxWF0uBT/7pjj7rFwvs6Ku4LvUXYDFDkEL1DB6ep fDDxuCzSt2iaMNiWKOvTk0YVrotWeuFXi3TAvgKYgozJqPdjeUzOqZPzsWJTxS43 1FSOyp4hlxs8lxu4JIeC =VnBP -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20170618145811.GA18477%40mutt. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Debian 9 Stretch and GPU support
https://www.debian.org/releases/stretch/releasenotes.en.html Will you update Debian Templates in QubesOS 3.2 to Debian 9 and also have this available in QubesOS 4? Also is there any ETA when you will support full GPU support and passthrough for VMs in Qubes? This could especially be handy for Windows VMs and Gamers obviously :) -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/07364f48-033e-47b0-8d7b-8390a05915ac%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
