Re: [qubes-users] Intel ME and AEM/HEADS
Le jeudi 31 janvier 2019 à 14:21 +0100, Maillist a écrit : > INTEL_CHIPSET_LOCKDOWN Nice feature. This makes impossible to update BIOS without physical access to the chip. I was unaware of this feature, thanks. -- 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/81b171b7d9667d677e79112573d7f04efaa6a072.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Intel ME and AEM/HEADS
Le mercredi 30 janvier 2019 à 12:38 +0100, Maillist a écrit : > Only if you configure it that way.Also, even if you do, you wanna > make > sure it only accepts updates signed by your personal key. Interesting. Could you point out the documentation explaining how. Thanks. -- 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/c8a1202447372be643cfeac7cec08507207c5025.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Intel ME and AEM/HEADS
Le mercredi 30 janvier 2019 à 15:50 +0700, Frank Beuth a écrit : > Apologies again if this is offtopic, but it sounds like there is a > way to > disable software reflashing of Coreboot entirely? Or am I > misinformed? https://doc.coreboot.org/flash_tutorial/index.html Quoting : "Updating the firmware is possible using the internal method, where the updates happen from a running system, or using the external method, where the system is in a shut down state and an external programmer is attached to write into the flash IC." After flashing coreboot, your bios is wide open for reflashing. Personally, this is what stops me from adopting Coreboot. -- 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/5908b07983d70cca378c7bd343069fdb8e2ad49d.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Intel ME and AEM/HEADS
Le mercredi 30 janvier 2019 à 13:07 +0630, Frank Beuth a écrit : > Apologies if this is getting offtopic, but: one author suggested that > modern > versions of Coreboot could (in absence of Intel ME or AEM) reduce > Evil Maid > attacks to physical attacks requiring the attacker to open the laptop > and > physically reflash the SPI flash. > > Does this sound correct? When flashing Coreboot for the first time, you usually need an SPI flash cable with physical access to hardware. On some low-end boards, you may flash directly without physical access. Once Coreboot is installed, you can reflash your bios within GNU/Linux using flashbios utility. In this case, Coreboot offers no bios protection. Coreboot developers have beend asked for a password protection, but they think it is useless and will not develop such a feature. The advantage of Coreboot is that it claims to be able to disable or limit Intel ME backdoor. In recent versions, Coreboot embeds Intel blobs, so installing a limited version of Intel ME might not be sufficient to completely disable it. -- 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/6f0b9fbb3c131a97ea71fed7b88660adcc181de4.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] QSB #46: APT update mechanism vulnerability
Le mardi 29 janvier 2019 à 02:24 -0800, goldsm...@riseup.net a écrit : > To Alexandre > So you found this stuff on the internet and were gullible enough to > swallow it, hook line and sinker, without first verifying its > authenticity. I suppose your allegations against the Debian Team's > security keys are based on equally unstable foundations. > > The making of serious random and unsolicited allegations with the > intention of scaremongering, could be described as TROLLING. No, but I talked to Debian developers and attended Debian conferences in the past. The main GPG key of Debian distros is only protected by a password, not even a smartcard. Today, this is not enough. All Debian developers should sign code with a smartcard and the main GPG key should be protected in an HSM. Unless this is the case, you can consider Debian keys as "compromised". Please note that I have been using Debian since 1998. But at least I am aware of the lack of security of Linux distros. -- 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/7dbc4834141e628eeb6d79a0560ac9bd03b19560.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] QSB #46: APT update mechanism vulnerability
Le mardi 29 janvier 2019 à 09:51 +0200, Ilpo Järvinen a écrit : > Yeah yeah, the only modification was that chip as claimed in the > article? > Magically all the necessary signal pins were routed to its location > but nothing else was changed (and you cannot have that many pins in > that sized chip anyway which will seriously limit the possible > functionality > and processing speed). ...But it must all be true and present in > thousands > of servers because a sensational article so claims (funny though that > the > so claimed victims of the attack consistently denied presence of such > a > chip in their servers but I guess you'll anyway think they must be > lying > for the benefit of the Chinese, damage control, because of the > "investigation", or whatever reason). Good point. Obviously, this article has had access to classified informations and is part of a new "name and shame" policy. So can we trust it? My personal opinion is that adding backdoors in consumer electronics is like an arms race. Once it starts, it cannot and will not stop. -- 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/396a2f398ea08e9a9f4b4f362629d6422ae0454b.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] QSB #46: APT update mechanism vulnerability
Le mardi 29 janvier 2019 à 00:59 +0200, Ilpo Järvinen a écrit : > There are many technical reasons raising from plain > physics/electronics > which make an attack chip of that size with the described > capabilities to > seem quite utopistic (and the article therefore bogus). ...But of > course > you can choose to believe what you want. The Chinese chip has been found and exists, no doubt about it. It was found on thousands of servers, so I believe it is being analyzed. -- 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/5f5d8eaa5e35a8774d2aa67fbb096c0f7270b126.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] QSB #46: APT update mechanism vulnerability
Le lundi 28 janvier 2019 à 13:08 -0800, goldsm...@riseup.net a écrit : > I'm intrigued how you know can catagorically state "CAs and GNU/Linux > distributions are #1 targets for national China: https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies China uses a tiny chip to intercept data. Read Bloomberg article. "A chip can also steal encryption keys for secure communications, block security updates that would neutralize the attack, and open up new pathways to the internet." US: https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine.pdf The US are using Intel ME backdoor to take complete control of a computer using a built-in VNC server and shadow connections. "Has built-in full-fledged web and VNC servers" (page 20) So my assumption was that all these backdoors were made for the primary targets of stealing secret keys. Game-over. Once the private keys have been stolen, "mirage Internet". At the state of technology, I don't want Qubes users to believe that Qubes is secure. Qubes is INsecure. -- 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/4cbe82097aedd67b76c1e95293e8615266256591.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] QSB #46: APT update mechanism vulnerability
Le lundi 28 janvier 2019 à 13:08 -0800, goldsm...@riseup.net a écrit : > To Alexandre Belgrand > > I'm intrigued how you know can catagorically state "CAs and GNU/Linux > distributions are #1 targets for national > intelligence agencies". This is classified information and therefore > only available to a "Spook". Otherwise, it's entered the public > domain > via say a whistle blower like Ed Snowden. If that's how you came upon > it, please state the source and location. I am not a whistle blower, but I believe that all CAs and GNU/Linux distributions are primary targets for Intelligence agencies. This is not secret, this is why I am writing it, sitting behind my real IP. You will find this information on Internet. Look for the recent problems with China for example. Stealing root certificates allow Intelligence agencies to set-up mirage Internet : i.e. decrypt SSL/crypted content and present modified content to the user and make man-in-the-middle attack. Think about Debian private keys. The keys are stored on a server in a datacenter, not even on smartcards. What can stop a remote attacker with a remote console (either directly or using Intel ME) from stealing the keys and then breaking password using a keylogger in Intel ME. Answer : nothing can stop a local government from doing so. Think about SSL X509 certificates. To deliver encrypted content, the private key has to be on the server. You only need serial console access to steal the private key. The only solution is to compile the same bytecode and verifying hashes online, but Debian is lagging behind important patches, because they don't understand what already happened. -- 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/7855e6cc67bad1e8aca6e6837426a63869e5289c.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] QSB #46: APT update mechanism vulnerability
Le lundi 28 janvier 2019 à 16:47 +0100, qubes-...@tutanota.com a écrit : > What do you yourself use? Hope I can answer too. I use an X230 with Intel ME disabled from BIOS. It costs about 160€ on the second hand market and it has pretty decent hardware. Lenovo claims that Intel ME can be disabled, but Intel ME is still running and may accept remote shadow connections given a signed certificate from Intel. This is why I am only reading the mailing list and not using Qubes. At present, I consider Qubes as an interesting development, but not reaching its goals because dom0 can be penetrated using Intel ME. I am quite amused by tails sending an update command on each boot. You can be sure to light red light in a control center and be penetrated within seconds if need be. Remember that governments have control of most outgoing nodes. So neither do I use Tor. You just can't simply store valuable documents on a computer when connected to a network. Companies that care about security should have a complete process to manage workstations and internal networks, without access to the Internet. We are back to ancien times. Kind regards, Alexandre Belgrand -- 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/84ef99dc3a6aad1e8e035b5dda640ed306d27792.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] QSB #46: APT update mechanism vulnerability
Le dimanche 27 janvier 2019 à 16:47 +, unman a écrit : > I'd be interested to know what system has been graced with your > approval. > If you believe all this, then what makes you think that national > intelligence agencies haven't infiltrated *bsd, coreboot and any > other > system you can name. > imo Qubes does a reasonable job of providing a more secure system > that's usable by ordinary users. Simply no x86 system is reasonably secure. > Spreading unfounded allegations is a disservice to the community. Qubes is interesting because it is trying to answer security needs and the design is nice. But think about Intel ME backdoor. Imagine that any officer with a signed certificate of Intel can penetrate dom0 in your computer within seconds and then view your screen, move your mouse and type on your keyboard. This is reality and Qubes cannot change it. -- 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/65d4efc1f6cc5203a5fc0802e2cdff2e9fc992f7.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] QSB #46: APT update mechanism vulnerability
Le dimanche 27 janvier 2019 à 13:11 +, Holger Levsen a écrit : > I *believe* they probably misunderstood evil32.com and it's fallout. CAs and GNU/Linux distributions are #1 targets for national intelligence agencies. Debian developers are not using smartcards to store their GPG keys, including the master key signing code. It is very likely that Debian master key has been stolen. I would be very surprised if it had not been stolen. One reason why nobody wants to use SSL, including OpenBSD, is that there is a wide belief that SSL private keys have been stolen. Therefore there is no need to use SSL, as it does not offer a real protection. This is simply GAME OVER (part 1 of the game). One reason why I am not using Qubes, is that it does not offer a real protection compared to Debian, as both systems are IMHO compromised. At present, any government with a valid certificate from Intel can use Intel ME backdoor to access all resources from a computer, including keyboard and screen and there is no way to secure an X86 computer. If Qubes was making a wide use of Smartcards with a separate pinpad reader and was using a hardened operating system like OpenBSD or even a hardened GNU/Linux, I would have a closer look at it. -- 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/1d33856a9f5065d64564649bd56b6a0b6d746d7c.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
Le samedi 26 janvier 2019 à 04:39 -0800, goldsm...@riseup.net a écrit : > If "apt-transport-https" is the magic bullet, why in the past hasn't > it > been implemented by default? And, why for the future, is it not being > implemented immediately by Qubes, Debian et al? Furtermore, very few Debian repos support https. Here is the stanza to use https in Debian (adapt it for other flavors): deb https://deb.debian.org/debian/ unstable main contrib non-free deb-src https://deb.debian.org/debian/ unstable main contrib non-free -- 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/4e0a5edcde58d2ce674a85bd67201f57f4dfc401.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] QSB #46: APT update mechanism vulnerability
Le mercredi 23 janvier 2019 à 18:05 +0100, Marek Marczykowski-Górecki a écrit : > We have just published Qubes Security Bulletin (QSB) #46: > APT update mechanism vulnerability. Keep in mind that all PGP Debian/Ubuntu signing keys have been stolen and injection may occur during apt-get install/update using man-in-the- middle attack, at least in some countries. Unless packages are compiled with reproducible builds and fingerprints are available online, there is no way to avoid such an attack. -- 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/16d91083bd8dbf847a75b8548de0c1b8ac5a58bc.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] More information needed about Qubes security
Le lundi 14 janvier 2019 à 07:16 -0500, Chris Laprise a écrit : > Check out Joanna's blog at Invisible Things Lab. Lots of Qubes' DNA > is > there. Got it, thanks: Intel x86 considered harmful https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf -- 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/24905b36b567cf92ddb59a785739bc9ced0cbe56.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: More information needed about Qubes security
Le lundi 14 janvier 2019 à 03:26 -0800, Foppe de Haan a écrit : > can the IME really talk to any NIC? Or just the ones that it has > drivers for (e.g., other intel products)? If the latter, wouldn't an > add-in card (or USB dongle) solve that issue? It seems that the IME is a complete computer with direct access to northbridge and southbridge and can intercept any signal on the host and replace any firmware. So sniffing USB to reassemble network traffic should not be impossible. Read Blackhat presentations : Slides: https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine.pdf PDF: https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine-wp.pdf -- 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/11dd0a11860b16f6af79272bbaa63754792ff125.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Using a Desktop Computer with Qubes (R 4.0.1)
> So in theory you would plug your scanner which should appear in sys-
> usb,
> and you'd attach ("proxy") it to a VM where you have your scanning
> software installed. If you're lucky it will work that way but not
> every
> USB device works well with proxying and scanners aren't know to be
> very
> plug friendly. In that case you will have to use sys-usb
> directly
> (either for firmware loading - most scanners need that nowadays - or
> for
> firmware loading + scanning software).
> That's also why you have the option to combine sys-net and sys-usb
> into
> one VM during installation time: some USB networking devices can't be
> proxied so the only way to use them is to have the usb controllers in
> sys-net (or symmetrically, networking support in sys-usb).
Sounds reasonable. I am using a sane scanner which requires no
firmware, so it should work.
> Ditto for the smartcard reader...
OpenSC is pretty standard. I am using a stock CCID smartcard reader.
Should also work.
Thanks !
--
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/115311007a404367071fe0d23d893a0942bac876.camel%40mailbox.org.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] More information needed about Qubes security
Hello, I am still brooding over before installing Qubes. My first thinking is that since Intel ME backdoors provide full access to authorities, there is no way we can stop government agencies. Recent research (read 1) shows that Intel ME has access to all parts of a computer, even switched-off. This is not an NSA problem. If the NSA can do it, then any government agency including the Chinese, the Russians, the Germans, the French, India, etc .. can break into anyone's computer. Intel ME even includes a VNC server (VNC is crap), which should be able to display dom0. Intel ME has direct access to network cards and connections are routed to the Intel ME before they reach the network stack. Therefore, network connections from intruders should be invisible to dom0 and other cubes. There is also the alternative to switch to Coreboot and try to disable Intel ME. But I read that on my laptop, a Lenovo Thinkpad X230, it was impossible to completely remove Intel ME. Intel ME is constantly monitoring hardware and if it is removed, the computer will reboot after 30 minutes. In the X230 legacy bios, I disabled Intel ME completely, but a test in Gnu/linux shows it is still active. Also, when installing Coreboot, I loose Lenovo's frequent BIOS updates, and I am not very sure to be protected against Intel meltdown and Spectre. So a reasonable approach to me is to rely on a firewall and monitor incoming and outgoing packets. Network surveillance is IMHO the only way to discover an attack. I am using PC Engines APU with coreboot and open hardware, which is the best I can find in my price range. Network surveillance is how I discovered last time that my computer had been hacked, when I saw packets flowing to China. Since then, now I keep no personal document on a computer. When I discovered Qubes, it caught my eye but ... (a) It does not protect from Intel ME backdoors. (b) Has a Linux firewall running on a normal Fedora kernel, not even compiled statically with a limited number of modules. This firewall can be replaced with OpenBSD as discussed on the mailing list. (c) Using Coreboot might be an alternative, but I don't know how secure is Coreboot against other attacks. So my first opinion would be that Qubes can only protect against a simple software attack, not a complex hardware attack. What's interesting in Qubes is that : (d) It has reasonable defense in depth, at the scale of today's hardware. (e) It has good privacy protection. For example, it can protect me and my family when surfing on Internet and keep my data private. If you can tell me anything more about Qubes security, I am really interested. I am still waiting for more information before stepping on. (1) What we have learned about Intel ME http://blog.ptsecurity.com/2018/11/what-we-have-learned-about-intel-me.html -- 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/4715d81e5d1075fed58ddb92d4ec580efcb5171a.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Using a Desktop Computer with Qubes (R 4.0.1)
Le lundi 14 janvier 2019 à 01:52 +, js...@bitmessage.ch a écrit : > It sounds like you've already looked at the docs but here's the link: > https://www.qubes-os.org/doc/usb/ > You have to have sys-usb to attach a usb device like a scanner to an > appvm (unless you can just attach the whole usb controller, which > you > can't). Pardon my ignorance, I am planning to install Qubes on a laptop. I need to connect to (1) a USB scanner and (2) a USB smartcard reader (with OpenSC). In the documentation it is written: " Note, you cannot pass through devices from dom0 (in other words: a USB VM is required). To use this feature, you need to have the qubes- usb-proxy package installed in the template used for the USB qube " Does it mean I will have to create a USB VM and then connect it to other VMs using USB proxy. And I will loose USB keyboard and mouse in dom0. So is the only solution to buy a USB card and plug it in the laptop? Kind regards, -- 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/dcb8712b169a3b4e5cb1ea6434fd884583a7e448.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Using OpenBSD as Qubes firewall
Le lundi 14 janvier 2019 à 00:35 +, unman a écrit : > You can find some notes that may help here: > https://github.com/unman/notes/blob/master/openBSD_as_netvm Thanks. This seems very interesting. -- 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/01f7a6b66384b523077051342afc470298207742.camel%40mailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Using OpenBSD as Qubes firewall
Dear all, Pardon my ignorance, is it possible to use OpenBSD to provide firewalling to Qubes? I have nearly zero confidence in GNU/Linux although I use it everyday. Kind regards, -- 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/188087795.85612.1547407738605%40office.mailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] OpenSC smartcards + LVM
Dear all, This is my first post, so I would like to thank the community for the hard work around Qubes. Here are some questions before I consider replacing my system with Cubes. 1) OpenSC smartcards I would like to use OpenSC smartcard with pinpad reader to secure my SSH key. The pinpad reader is a USB device. Is Qubes suitable for that? Shall I create a minimal debian template, install OpenSC and libccid, allow USB device. Then shall I run a disposable VM each time I want to access a remote server using SSH? 2) Disc access + LVM What is the technology used for disc access? The question is that I am considering running a PostgreSQL database and it might be running slowly on a disc image. I read in documentation that dom0 had its own LVM logical volume (LV). I also read that VMs were stored in a disc image. Can VMs have their own logical volume ? Kind regards, -- 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/1106738391.57850.154731205%40office.mailbox.org. For more options, visit https://groups.google.com/d/optout.
