[qubes-users] Re: External monitor not getting highest resolution
Same thing is happening to me since the last Dom0 update. My ultrawide 29" LG external screen stopped working at the native 2560x1080 resolution and instead is working at 1920x1080. I have a Lenovo Thinkpad T430s. I was using nouveau driver but the same thing is happening with the integrated Intel graphic card. Fortunately I had a full backup from August 9 so, reinstalling Qubes 3.2 and restoring Dom0 and all the VM the problem is, temporarily, fixed and I have back 2560x1080 resolution. But the most maddening thing is that I tried several different distro (Linux Mint 18.2, MX 16.0, Manjaro) and I have the same problem. Only 1920x1080px. In the previous 1.5 years I had no problem of resolution with Qubes 3.2 and Linux Mint 18.1. Tried cvt and xrandr --newmode and --addmode to no avail so far (no effect on Qubes, screen blanked on Linux Mint). Again, any idea? 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/52103ef6-b9a4-43e3-8c4c-17a85ac0a3de%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: secure hardware after purchase but before qubes installation
On 09/07/2017 02:40 PM, pixel fairy wrote: sun microsystems, now part of oracle, used capsules with beads and adhesive to detect rough handling in shipment. have not seen anyone else adopt that. purism was looking into this as well. tamper proof tape is easily defeated. i suggested glittery nail polish and a signed photograph on a login page and sent in email to the buyer. As always I would like to remind people that purism isn't worth the money, their laptops are simply quanta rebrands with a few slight improvements that one can do themselves for much less money - their relentless pursuit of the latest intel hardware means they will never be free. your best bet is show up in person. dont even think about lenovo unless its 2013 or before and you trust its previous owner. they already shipped too much malware, even in bios, out of the factory. I would suggest a Lenovo G505s, it is owner controlled (no ME/PSP or code signing) and mostly open source with coreboot (the blobs can be open-sourced as there is no code signing anti-features) - and it supports Qubes 4.0. Reflash the firmware and you would be fine, other than that I highly doubt anyone on this list is even remotely on the radar of an organization that would have both the technical abilities and the authority to subvert a letter carrier - one needs a warranty to intercept USPS first class, priority and expressmail and they take their jobs more seriously (whereas it is much easier to bribe FedEx Home's "independent contractors" aka the gig economy scam) Why do you guys use qubes anyways? (feel free to message me off list) I can't understand why everyone is so paranoid - I only use it for the personal security pride as an IT person I would feel silly if I had poor security and got hacked despite having nothing worth stealing. -- 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/b01e7bed-c716-8016-b01c-1cc0dd3e2206%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Lenovo X230 - List of USB-Ports and USB-Controllers (Layout)
Excellent - an x230! Have you installed coreboot on it? Those sandy/ivybridge thinkpads have open source init and support all of me_cleaner's features -- 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/b312612b-1099-73b0-0b7f-a092d17c7e8b%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
One can use coreboot with grub's kernel signing features on an owner controlled non PSP/ME PC such as the Lenovo G505 (laptop) or KCMA-D8 (workstation), then after coreboot is working you enable the flash write restriction so that it can't be flashed internally (an attacker would have to have physical access for around 10mins to reflash) - this is technically superior to "secure boot" as it is owner controlled by you instead of microsoft. You can also use AEM if you purchase the TPM accessory. The Libre OpenPOWER9 TALOS 2 server/workstation (also owner controlled) features kernel signing features as well including some special sauce from raptor - if you have the money to buy new server/workstation class professional grade hardware it is a good deal for what you get and would last 10 years before you need to upgrade seeing as how powerful it is (the entry level 4 core CPU has 12 SMT threads, much better than intels non-SMT hyperthreading.) As always I am more than happy to assist someone with purchasing and configuring libre devices and the security features present. -- 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/c317cfb0-16f5-bfad-d63c-cc5e9aa74210%40gmx.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: re-use qemu qcow2 image for qubes-os
Have you tried the Startup Wizard Fix under Windows 7 boot? On Wednesday, 6 September 2017 21:17:41 UTC+10, peter.p...@gmail.com wrote: > I try to use an existing win7 qemu qcow2 image with qubes os R3.2 > > The image does not boot. I tried various xml settings for the drive image > inspired by > > https://wiki.libvirt.org/page/After_import_a_guest_from_an_existing_disk_image_using_virt-install,_the_guest_starting_stalls_with_%22No_boot_device%22 > > but no success. Converting to raw is not an option. > > What can I do? > Thanks, > Peter. -- 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/3a6c26ef-a63c-4827-8a4b-75a3662447ca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Internet Connection Is Slow
Can you ping the router? Can you ping your external IP? Can you ping out from other Guests? Do you have a Gateway or just the guest? Have you run the monitoring tools on the gateway? If you run 'ifconfig' do you have an IP? If you run 'route', do you have any routes? On Friday, 8 September 2017 07:29:46 UTC+10, Person wrote: > On Thursday, September 7, 2017 at 9:27:02 PM UTC+8, Marke50 wrote: > > On Thursday, August 31, 2017 at 10:46:13 PM UTC-4, Person wrote: > > > When I connect to a WiFi network, Qubes says I am connected, but websites > > > don't load at all. There is only a connecting sign for who knows how > > > long. I have no idea what to do because otherwise, Qubes is working fine. > > > > When you say Qubes, is this from a VM? if so which NetVM is the VM > > associated with. > > Well, I am using Qubes-Whonix, so this problem can be found in anon-whonix > and also the sys-net and another NetVM. It seems to apply to all of them, so > it can't be the problem of the VMs, the browsers, or the WiFi itself. > > If I had to guess, there is a problem with the proxy (Firefox forces me to > choose "Manually enter a proxy" but I haven't entered any proxy yet). -- 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/56bd0f23-9e4d-4284-9b6f-7e593cefc850%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 3.2 Error when Re-Installing of Qubes Windows Tools 3.2.2.3
W dniu czwartek, 7 września 2017 22:49:06 UTC+2 użytkownik PR napisał: > Hello Yethal, > > > On 09/06/2017 11:14 PM, Yethal wrote: > > W dniu środa, 6 września 2017 19:31:03 UTC+2 użytkownik PR napisał: > >> on my Windows 7 HVM USB devices could not be recognized when beeing > >> attached via sys-usb > >> (...) > > I'm 99% sure you can't attach single usb devices to windows vms. Only > > entire pci controllers can be attached via qvm-pci > > Thank you for the hint, I have examined the USB-Controller-Layout of my > Lenovo X230 and came to the conclusion to pass USB 3.0 Controller to my > Windows HVM as I will only loose 2 out of 3 USB-Ports to my Windows > AppVM and my internal LTE-Card which is also connected to the same > PCI-Controller. > > After adding the PCI-Controller to my Windows HVM I had to set > pci_strictreset false to be able to boot into windows. > > When looking under devices, the controller is not listed as USB controller. > Instead I see two entries with a yellow warning sign under "Other devices": > > - Universal Serial Bus (USB) Controller > - XP001 XENBUS VBD > > Any idea what is missing to get USB support in my Win7 HVM? > > Regards > > - PhR You need to install the USB 3.0 driver within the Windows VM. -- 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/84d798ef-195b-403c-9473-1dc67d64aae7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Internet Connection Is Slow
On Thursday, September 7, 2017 at 9:27:02 PM UTC+8, Marke50 wrote: > On Thursday, August 31, 2017 at 10:46:13 PM UTC-4, Person wrote: > > When I connect to a WiFi network, Qubes says I am connected, but websites > > don't load at all. There is only a connecting sign for who knows how long. > > I have no idea what to do because otherwise, Qubes is working fine. > > When you say Qubes, is this from a VM? if so which NetVM is the VM > associated with. Well, I am using Qubes-Whonix, so this problem can be found in anon-whonix and also the sys-net and another NetVM. It seems to apply to all of them, so it can't be the problem of the VMs, the browsers, or the WiFi itself. If I had to guess, there is a problem with the proxy (Firefox forces me to choose "Manually enter a proxy" but I haven't entered any proxy yet). -- 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/2d51be3e-8139-431b-8fb6-886176fd93b8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 3.2 Error when Re-Installing of Qubes Windows Tools 3.2.2.3
Hello Yethal, On 09/06/2017 11:14 PM, Yethal wrote: W dniu środa, 6 września 2017 19:31:03 UTC+2 użytkownik PR napisał: on my Windows 7 HVM USB devices could not be recognized when beeing attached via sys-usb (...) I'm 99% sure you can't attach single usb devices to windows vms. Only entire pci controllers can be attached via qvm-pci Thank you for the hint, I have examined the USB-Controller-Layout of my Lenovo X230 and came to the conclusion to pass USB 3.0 Controller to my Windows HVM as I will only loose 2 out of 3 USB-Ports to my Windows AppVM and my internal LTE-Card which is also connected to the same PCI-Controller. After adding the PCI-Controller to my Windows HVM I had to set pci_strictreset false to be able to boot into windows. When looking under devices, the controller is not listed as USB controller. Instead I see two entries with a yellow warning sign under "Other devices": - Universal Serial Bus (USB) Controller - XP001 XENBUS VBD Any idea what is missing to get USB support in my Win7 HVM? Regards - PhR -- 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/07346c49-ac79-1919-7735-25107d649f91%40googlemail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qrexec daemon error in sys-usb
Hello, my sys-usb (based on f-24-minimal) on Q3.2 was running perfectly - until I decided I need rsync. First dnf suggested some updates that I accepted, the I installed rsync in the template. I got a strange message "sending to .. dom0" and then "refused". OK, sometimes I get strange messages, so I shut the template down & want to reboot sys-usb. It won't. I get the qrexec daemon error, and then it dies. Is there some hint available how to get this fixed? Need a Coldboot ??? Thanks, 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/eb993aad-f59e-947e-3a80-3dcf251d2364%40web.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] 3.2 after dom0 update and fresh 4RC1 fail to run on AMD A10-9600P Notebook
I installed a Qubes OS 3.2 on a HP Notebook (https://support.hp.com/us-en/product/hp-15-ba000-notebook-pc-series/10862317/document/c05411358) with a AMD A10-9600P core. This worked fine, however since my WiFi was quite slow I did an update of all VMs including dom0 (I know, i probably could have skipped dom0 what I also will do in future). After that Qubes OS was unable to start. After the disk password it is stuck on black screen or in the terminal. There were a lot of errors where I don't know which may be relevant, I remember a lot of APIC_ERROR but there was definitely more. Next I tried to install a fresh Qubes OS 4 RC1 in the exact same manner I did with the 3.2. This never makes it to the graphical install screen and is stuck in a plain black screen after I hit install from the boot menu (which loads correctly). I'll simply installed 3.2 again and won't update dom0 so I guess I will be fine. However is this kind of problem known? Is it related to Fedora 25 or XEN? And can it be worked around? (Afterall having a more recent software and drives still could be nice ;-)) 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/7314fdda-cfe6-480d-85dd-e4f5a83402ca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: secure hardware after purchase but before qubes installation
sun microsystems, now part of oracle, used capsules with beads and adhesive to detect rough handling in shipment. have not seen anyone else adopt that. purism was looking into this as well. tamper proof tape is easily defeated. i suggested glittery nail polish and a signed photograph on a login page and sent in email to the buyer. your best bet is show up in person. dont even think about lenovo unless its 2013 or before and you trust its previous owner. they already shipped too much malware, even in bios, out of the factory. -- 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/394af50f-1103-4d39-b009-e48f1044a4b5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Lenovo X230 - List of USB-Ports and USB-Controllers (Layout)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/07/2017 07:07 PM, 'PhR' via qubes-users wrote:
> One question: why the first USB-Controller doesn't seem to connect
> any USB-devices/-ports.
>
> I have attached each of the 3 USB-Controllers to my sys-usb AppVM
> and then looked up which USB-devices are recognized ('lsusb' in
> sys-net) and tested out which USB-Ports work.
>
> Any idea what is happening with the first Controller?
Probably it is connected to the optional docking station, and it's ports
.
- --
Zrubi
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJZsZAPAAoJEH7adOMCkunmq8IQAJyQ78/kwgSf60jTJA6XdJ0A
9IHc7oaKuQKaYeUAoLQNj40zsU1/hxjUudonsnk+SKhgrQuLhiM2cT5L/eeAwtsI
SkUku2SyskS3iA+oFZPTeww2fj/XmqKSaqSq4eWKud5uoILEeWTKxowmyffryTHo
0T7pNJ5AljiP5emcCv5DFT/HLKDKiiWT5hYVPdUfZj6Z8/LyEvai1qdLwfEdXkGy
rTDF/W+kOFR8s89DWGZSmOokixSIRS6ZjNZ2dukucoub8tddp3KwA91HikPaHqTp
lW9iA0WB+OOyeLvD18vrR5Iw4vq7kdHFsy8e9ohMxJ+x14JVsE5KrNfjL1/zXshm
LKyE/sH4jp0MILd2yEKhYFLfDz/Gbe6vOic0eVRUzw+FCZdM1IOJY/NhUMp5v/6/
vzWaihZjJ4OM5l2Eze90Y98tO7HNZXo48i7/XKyrtElZusKwKFowH8fZPkdtGL8q
1CuecHvE51mDwJdAWmxPa0MmeDuqjzF/7tvEn9OKFy/K/DdnAtWPxtq+TTDOWyWD
/0/J7wF1bLaZnwc8f7X7rv1Q0K+fgw2R7oUIm+5/Y7JmoLycqVFxGhmCrgxty81P
CXeypsECIwPOaw9r5EClL91dVdPB/o4sSOy8jL7nQ47CINgqepwzGBF8j+1INBju
XWQ9E2zUuYhxK1dUwQvk
=dZCe
-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/60f06b61-0e78-a0af-cb6e-c0ee15c64310%40zrubi.hu.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Lenovo X230 - List of USB-Ports and USB-Controllers (Layout)
Hello,
an interesting question that might influence the answer "Which Laptop
should I buy" can be the way USB-Ports and internal USB-devices are
connected to the USB-Controllers.
In cases where you need to pass through a whole USB-PCI-Controller to an
AppVM this influences which other (internal) USB-devices and Ports you
"loose" to this AppVM.
I recently bought a refurbished Lenovo X230 (150 Eur) added 16GB RAM and
a SSD and it runs superb under Qubes 3.2.
There the design of the USB-Ports/USB-Devices of the X230, which might
also be helpfull to others:
00:1d.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family
USB Enhanced Host Controller #1 (rev 04)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate
Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
00:1a.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family
USB Enhanced Host Controller #2 (rev 04)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate
Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
=> Bus 002 Device 004: ID 04f2:b2eb Chicony Electronics Co., Ltd =
720p HD Integrated camera
=> Bus 002 Device 003: ID 0a5c:21e6 Broadcom Corp. BCM20702
Bluetooth 4.0 [ThinkPad]
=> connects to: Right USB-Port (next to Ethernet-Port)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB xHCI Host Controller (rev 04)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
=> Bus 002 Device 002: ID 0bdb:1926 Ericsson Business Mobile
Networks BV 1 = LTE/WAN-Card
=> connects to: Left USB-Port (next to VGA-Display-Out)
=> connects to: Left USB-Port (next Mini-DisplayPort-Out)
One question:
why the first USB-Controller doesn't seem to connect any USB-devices/-ports.
I have attached each of the 3 USB-Controllers to my sys-usb AppVM and
then looked up which USB-devices are recognized ('lsusb' in sys-net) and
tested out which USB-Ports work.
Any idea what is happening with the first Controller?
Kind regards
- PhR
--
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/6e8fa373-ca08-b133-4cc5-32eb4109abaa%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
On Thursday, September 7, 2017 at 12:49:05 PM UTC-4, cooloutac wrote: > On Thursday, September 7, 2017 at 9:40:47 AM UTC-4, Patrik Hagara wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > On 09/07/2017 03:21 PM, cooloutac wrote: > > > On Tuesday, August 29, 2017 at 12:46:04 PM UTC-4, Patrik Hagara > > > wrote: On 08/29/2017 06:25 PM, cooloutac wrote: > > On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik > > Hagara wrote: On 08/29/2017 04:50 PM, > > cyberian@national.shitposting.agency wrote: > > >>> Leo Gaspard, > > >>> > > >>> I have read about AEM but have never used it, it seems > > >>> like it is geared towards protecting from USB's with > > >>> malicious firmware on them. > > >>> > > >>> Does AEM actually verify the integrity of /boot before > > >>> using? This is what I am looking for, either a method > > >>> of encrypting /boot or even better, a secure method to > > >>> verify its integrity during boot > > >>> > > > > AEM does verify the integrity of /boot using the TPM > > seal/unseal operation. If any of the boot components change, > > AEM falls back to regular, unmeasured boot -- the user is > > expected to notice this and cease using the > > potentially-compromised system (the lack of explicit > > indication of failed AEM boot is deliberate, see the last FAQ > > item at [1]). > > > > The security provided by AEM is much more stronger than > > encrypted /boot could ever offer, because as already pointed > > out, there is always a little first-stage bootloader stub on > > the disk unencrypted and it would be easy to overwrite it > > with a malicious version that would intercept the encryption > > passphrase and exfiltrate it using eg. unused disk sectors. > > > > If someone did the above with AEM, the TPM would refuse to > > useal the AEM secret as the platform state would be > > different. > > > > The feature protecting dom0 from malicious USB devices [2] > > serves a different purpose and is not related to AEM. Plus, > > you always need to disconnect all untrusted USB devices while > > rebooting Qubes, regardless of whether you have USB qube set > > up or not. > > > > > > Cheers, Patrik > > > > > > [1] > > https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html > > [2] https://www.qubes-os.org/doc/usb/ > > > > my problem is unfortunately i can't keep buying new pc's. SO > > maybe its all for naught for me.. Also AEM does not seem as > > reliable as secureboot. Alot of issues on threads with some > > people. It seems complicated. even false alarms. But I really > > do think they are supposed to compliment each other. trusted > > boot and measured boot yes? AEM definitely comes in handy for > > people who would find it nescessary to buy new equipment. > > > > > > Well, it depends... If you can be reasonably sure that the > > > attacker did not modify any firmware (eg. the network card), you > > > could simply reinstall Qubes from a trusted install media and > > > restore VMs from a backup. This becomes trivial once stateless > > > computers [1] are a thing. > > > > > But I would still want an encrypted boot, if I was going to > > use aem, and key on a external usb disk, which > > unfortunately means I could not use a sys-usb. Am I wrong > > about this? Does this change in 4.0? > > > > > > It is possible to use AEM along with USB qube, you just have to > > > disable the early hiding of USB devices from dom0. But once Qubes > > > is fully booted and sys-usb started, you get the full USB qubes > > > protecion. > > > > > So this is where the what fits into you "security model" > > What are you more concered about. I assumed we had to choose > > between aem vs sys-usb? For people travelling with laptops > > in strange places where physical compromise is more likely > > aem is a good option. Some people would prolly not just buy a > > new laptop but know when to destroy theirs too lol. > > > > > > The only trade-off for AEM regarding USB devices is that the USB > > > stick you buy to install AEM on could be compromised already > > > (straight from the factory, or intercepted & infected during > > > shipping). And since you need to plug it directly into dom0 in > > > order to perform the install, it could exploit USB or filesystem > > > drivers and gain control of dom0. > > > > > > So it is kind of a trust-on-first-use scenario for the > > > installation step only. > > > > > > > > > Cheers, Patrik > > > > > > > > > [1] https://blog.invisiblethings.org/papers/2015/state_harmful.pdf > > > > > > Doesn't Qubes assume the netcard will be compromised, hence > > > untrusted. > > > > It does, but with compromised firmware the NIC can
Re: [qubes-users] Options for securing /boot
On Thursday, September 7, 2017 at 9:40:47 AM UTC-4, Patrik Hagara wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 09/07/2017 03:21 PM, cooloutac wrote: > > On Tuesday, August 29, 2017 at 12:46:04 PM UTC-4, Patrik Hagara > > wrote: On 08/29/2017 06:25 PM, cooloutac wrote: > On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik > Hagara wrote: On 08/29/2017 04:50 PM, > cyberian@national.shitposting.agency wrote: > >>> Leo Gaspard, > >>> > >>> I have read about AEM but have never used it, it seems > >>> like it is geared towards protecting from USB's with > >>> malicious firmware on them. > >>> > >>> Does AEM actually verify the integrity of /boot before > >>> using? This is what I am looking for, either a method > >>> of encrypting /boot or even better, a secure method to > >>> verify its integrity during boot > >>> > > AEM does verify the integrity of /boot using the TPM > seal/unseal operation. If any of the boot components change, > AEM falls back to regular, unmeasured boot -- the user is > expected to notice this and cease using the > potentially-compromised system (the lack of explicit > indication of failed AEM boot is deliberate, see the last FAQ > item at [1]). > > The security provided by AEM is much more stronger than > encrypted /boot could ever offer, because as already pointed > out, there is always a little first-stage bootloader stub on > the disk unencrypted and it would be easy to overwrite it > with a malicious version that would intercept the encryption > passphrase and exfiltrate it using eg. unused disk sectors. > > If someone did the above with AEM, the TPM would refuse to > useal the AEM secret as the platform state would be > different. > > The feature protecting dom0 from malicious USB devices [2] > serves a different purpose and is not related to AEM. Plus, > you always need to disconnect all untrusted USB devices while > rebooting Qubes, regardless of whether you have USB qube set > up or not. > > > Cheers, Patrik > > > [1] > https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html > [2] https://www.qubes-os.org/doc/usb/ > > my problem is unfortunately i can't keep buying new pc's. SO > maybe its all for naught for me.. Also AEM does not seem as > reliable as secureboot. Alot of issues on threads with some > people. It seems complicated. even false alarms. But I really > do think they are supposed to compliment each other. trusted > boot and measured boot yes? AEM definitely comes in handy for > people who would find it nescessary to buy new equipment. > > > > Well, it depends... If you can be reasonably sure that the > > attacker did not modify any firmware (eg. the network card), you > > could simply reinstall Qubes from a trusted install media and > > restore VMs from a backup. This becomes trivial once stateless > > computers [1] are a thing. > > > But I would still want an encrypted boot, if I was going to > use aem, and key on a external usb disk, which > unfortunately means I could not use a sys-usb. Am I wrong > about this? Does this change in 4.0? > > > > It is possible to use AEM along with USB qube, you just have to > > disable the early hiding of USB devices from dom0. But once Qubes > > is fully booted and sys-usb started, you get the full USB qubes > > protecion. > > > So this is where the what fits into you "security model" > What are you more concered about. I assumed we had to choose > between aem vs sys-usb? For people travelling with laptops > in strange places where physical compromise is more likely > aem is a good option. Some people would prolly not just buy a > new laptop but know when to destroy theirs too lol. > > > > The only trade-off for AEM regarding USB devices is that the USB > > stick you buy to install AEM on could be compromised already > > (straight from the factory, or intercepted & infected during > > shipping). And since you need to plug it directly into dom0 in > > order to perform the install, it could exploit USB or filesystem > > drivers and gain control of dom0. > > > > So it is kind of a trust-on-first-use scenario for the > > installation step only. > > > > > > Cheers, Patrik > > > > > > [1] https://blog.invisiblethings.org/papers/2015/state_harmful.pdf > > > > Doesn't Qubes assume the netcard will be compromised, hence > > untrusted. > > It does, but with compromised firmware the NIC can inject code into > the OS during early boot (before the NIC is isolated from DMA using > the IOMMU). AEM will catch/prevent this. > > > So good to know we can use a usb key with a sys-usb. IS there > > some sort of risk to doing this? Do we have to pull out the usb > > stick
[qubes-users] Vaio Z Canvas EFI installation issue - PLEASE HELP!!!
Qubes OS version R4.0 RC1 I am trying to install qubes 4.0 on my vaio canvas z model VJZ12AX0211S: The specs are: Display 12.3 in WQXGA+ IPS display touchscreen (2560 x 1704), 10-finger multi-touch support Processor Intel Core i7-4770HQ 2.20 GHz with Turbo Boost Technology up to 3.40 GHz Memory 16GB DDR3L 1600 MHz Hard drive size 512GB SSD Intel Iris Pro Graphics 5200 with shared graphics memory Ports 2 USB 3.0 (1 powered) • HDMI • Mini DisplayPort • Headphone output/Microphone input combo • LAN (10/100/1000) Wireless 802.11ac/a/b/g/n (Miracast enabled) Bluetooth Bluetooth 4.1 I've put the installer on USB, bios stared, secure boot disabled, etcIt starts but remain stuck after a few seconds. I can chose any install option but doesn't matter what,. it remain stuck after first 3 line of text. I don't have the legacy option in bios. Can you please let me know what should I do to install it? I've been tried the troubleshooting guide from the official page without any result. I've made the memory stick using DD method under debian. Please help -- 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/6a843f22-fb89-470a-ad2d-6f103b52c063%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/07/2017 03:21 PM, cooloutac wrote: > On Tuesday, August 29, 2017 at 12:46:04 PM UTC-4, Patrik Hagara > wrote: On 08/29/2017 06:25 PM, cooloutac wrote: On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik Hagara wrote: On 08/29/2017 04:50 PM, cyberian@national.shitposting.agency wrote: >>> Leo Gaspard, >>> >>> I have read about AEM but have never used it, it seems >>> like it is geared towards protecting from USB's with >>> malicious firmware on them. >>> >>> Does AEM actually verify the integrity of /boot before >>> using? This is what I am looking for, either a method >>> of encrypting /boot or even better, a secure method to >>> verify its integrity during boot >>> AEM does verify the integrity of /boot using the TPM seal/unseal operation. If any of the boot components change, AEM falls back to regular, unmeasured boot -- the user is expected to notice this and cease using the potentially-compromised system (the lack of explicit indication of failed AEM boot is deliberate, see the last FAQ item at [1]). The security provided by AEM is much more stronger than encrypted /boot could ever offer, because as already pointed out, there is always a little first-stage bootloader stub on the disk unencrypted and it would be easy to overwrite it with a malicious version that would intercept the encryption passphrase and exfiltrate it using eg. unused disk sectors. If someone did the above with AEM, the TPM would refuse to useal the AEM secret as the platform state would be different. The feature protecting dom0 from malicious USB devices [2] serves a different purpose and is not related to AEM. Plus, you always need to disconnect all untrusted USB devices while rebooting Qubes, regardless of whether you have USB qube set up or not. Cheers, Patrik [1] https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html [2] https://www.qubes-os.org/doc/usb/ my problem is unfortunately i can't keep buying new pc's. SO maybe its all for naught for me.. Also AEM does not seem as reliable as secureboot. Alot of issues on threads with some people. It seems complicated. even false alarms. But I really do think they are supposed to compliment each other. trusted boot and measured boot yes? AEM definitely comes in handy for people who would find it nescessary to buy new equipment. > > Well, it depends... If you can be reasonably sure that the > attacker did not modify any firmware (eg. the network card), you > could simply reinstall Qubes from a trusted install media and > restore VMs from a backup. This becomes trivial once stateless > computers [1] are a thing. > But I would still want an encrypted boot, if I was going to use aem, and key on a external usb disk, which unfortunately means I could not use a sys-usb. Am I wrong about this? Does this change in 4.0? > > It is possible to use AEM along with USB qube, you just have to > disable the early hiding of USB devices from dom0. But once Qubes > is fully booted and sys-usb started, you get the full USB qubes > protecion. > So this is where the what fits into you "security model" What are you more concered about. I assumed we had to choose between aem vs sys-usb? For people travelling with laptops in strange places where physical compromise is more likely aem is a good option. Some people would prolly not just buy a new laptop but know when to destroy theirs too lol. > > The only trade-off for AEM regarding USB devices is that the USB > stick you buy to install AEM on could be compromised already > (straight from the factory, or intercepted & infected during > shipping). And since you need to plug it directly into dom0 in > order to perform the install, it could exploit USB or filesystem > drivers and gain control of dom0. > > So it is kind of a trust-on-first-use scenario for the > installation step only. > > > Cheers, Patrik > > > [1] https://blog.invisiblethings.org/papers/2015/state_harmful.pdf > > Doesn't Qubes assume the netcard will be compromised, hence > untrusted. It does, but with compromised firmware the NIC can inject code into the OS during early boot (before the NIC is isolated from DMA using the IOMMU). AEM will catch/prevent this. > So good to know we can use a usb key with a sys-usb. IS there > some sort of risk to doing this? Do we have to pull out the usb > stick quickly after booting before system loads or something? Not sure about the currently available AEM version, but if/when my changes to AEM get merged, you get prompted to remove the AEM USB stick before Qubes will finish booting (so that the untrusted sys-usb cannot read the contents of the
[qubes-users] Restarting vm's /all
When I run updates to fedora I have to restart all the vm's that are running fedora obviously. Is there a command that will restart all vm's in order or a script that I could run? 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/633de37d-de0f-4d9d-9cb8-5f15b54067c9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: secure hardware after purchase but before qubes installation
On Thursday, September 7, 2017 at 9:27:35 AM UTC-4, cooloutac wrote: > On Friday, September 1, 2017 at 10:46:04 AM UTC-4, James Miller wrote: > > For those that run Qubes on an off the shelf computer, did you go through > > any special steps to insure the hardware was clean after you purchased, but > > before you installed qubes? I'm about to buy new hardware for my > > installation and I'm thinking of all the places in the purchase chain where > > a laptop could be compromised. Does anyone have advise on how to not become > > the one in a million person to get a laptop with compromised hardware? For > > example: > > Do I need to replace any parts just in case? > > Do I need to buy in person or directly from the manufacturer on line? > > I would literally get it off the shelf somewhere. Examine the box to make > sure its not used before buying. Thats what I do. > > I hate buying stuff from Amazon or Newegg, cause half the time its used, > opened in shipment. UPS is very corrupt. Some of them are also crazy and > play soccer with your packages. > > One way to determine if its fresha and clean when buying some parts, is they > come with stickers. Gpu, CPU, MObo, and memory sticks always come with > manufacturers stickers to put on the case. IF the sticker is not in there, > its used. > > For example I just ordered some more g.skill ram, The original ram I bought > from microcenter had the sticker. The same exact ram I got from newegg, > didn't. Now I don't think ram has firmware to be comrpromised? who knows. > also its a liftime warranty so I wasn't too upset. But these are things to > look for. Every single manufacturer I've ever bought puts a sticker in the box. So if you buy something and didn't get one. Its used period, no matter what you are telling yourself. -- 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/7310274b-0de5-418b-aae1-a5511071362b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: secure hardware after purchase but before qubes installation
On Friday, September 1, 2017 at 10:46:04 AM UTC-4, James Miller wrote: > For those that run Qubes on an off the shelf computer, did you go through any > special steps to insure the hardware was clean after you purchased, but > before you installed qubes? I'm about to buy new hardware for my > installation and I'm thinking of all the places in the purchase chain where a > laptop could be compromised. Does anyone have advise on how to not become the > one in a million person to get a laptop with compromised hardware? For > example: > Do I need to replace any parts just in case? > Do I need to buy in person or directly from the manufacturer on line? I would literally get it off the shelf somewhere. Examine the box to make sure its not used before buying. Thats what I do. I hate buying stuff from Amazon or Newegg, cause half the time its used, opened in shipment. UPS is very corrupt. Some of them are also crazy and play soccer with your packages. One way to determine if its fresha and clean when buying some parts, is they come with stickers. Gpu, CPU, MObo, and memory sticks always come with manufacturers stickers to put on the case. IF the sticker is not in there, its used. For example I just ordered some more g.skill ram, The original ram I bought from microcenter had the sticker. The same exact ram I got from newegg, didn't. Now I don't think ram has firmware to be comrpromised? who knows. also its a liftime warranty so I wasn't too upset. But these are things to look for. -- 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/bce58582-c1ee-48d1-bf1b-432bb61e5fab%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Internet Connection Is Slow
On Thursday, August 31, 2017 at 10:46:13 PM UTC-4, Person wrote: > When I connect to a WiFi network, Qubes says I am connected, but websites > don't load at all. There is only a connecting sign for who knows how long. I > have no idea what to do because otherwise, Qubes is working fine. When you say Qubes, is this from a VM? if so which NetVM is the VM associated with. -- 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/8d58f0e8-4c5c-47ca-9ff1-7188e7fccf01%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
On Tuesday, August 29, 2017 at 12:46:04 PM UTC-4, Patrik Hagara wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 08/29/2017 06:25 PM, cooloutac wrote: > > On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik Hagara > > wrote: On 08/29/2017 04:50 PM, cyberian@national.shitposting.agency > > wrote: > Leo Gaspard, > > I have read about AEM but have never used it, it seems like > it is geared towards protecting from USB's with malicious > firmware on them. > > Does AEM actually verify the integrity of /boot before using? > This is what I am looking for, either a method of encrypting > /boot or even better, a secure method to verify its integrity > during boot > > > > > AEM does verify the integrity of /boot using the TPM seal/unseal > > operation. If any of the boot components change, AEM falls back to > > regular, unmeasured boot -- the user is expected to notice this and > > cease using the potentially-compromised system (the lack of > > explicit indication of failed AEM boot is deliberate, see the last > > FAQ item at [1]). > > > > The security provided by AEM is much more stronger than encrypted > > /boot could ever offer, because as already pointed out, there is > > always a little first-stage bootloader stub on the disk > > unencrypted and it would be easy to overwrite it with a malicious > > version that would intercept the encryption passphrase and > > exfiltrate it using eg. unused disk sectors. > > > > If someone did the above with AEM, the TPM would refuse to useal > > the AEM secret as the platform state would be different. > > > > The feature protecting dom0 from malicious USB devices [2] serves > > a different purpose and is not related to AEM. Plus, you always > > need to disconnect all untrusted USB devices while rebooting Qubes, > > regardless of whether you have USB qube set up or not. > > > > > > Cheers, Patrik > > > > > > [1] > > https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html [2] > > https://www.qubes-os.org/doc/usb/ > > > > my problem is unfortunately i can't keep buying new pc's. SO maybe > > its all for naught for me.. Also AEM does not seem as reliable as > > secureboot. Alot of issues on threads with some people. It seems > > complicated. even false alarms. But I really do think they are > > supposed to compliment each other. trusted boot and measured boot > > yes? AEM definitely comes in handy for people who would find it > > nescessary to buy new equipment. > > Well, it depends... If you can be reasonably sure that the attacker > did not modify any firmware (eg. the network card), you could simply > reinstall Qubes from a trusted install media and restore VMs from a > backup. This becomes trivial once stateless computers [1] are a thing. > > > But I would still want an encrypted boot, if I was going to use > > aem, and key on a external usb disk, which unfortunately means I > > could not use a sys-usb. Am I wrong about this? Does this change > > in 4.0? > > It is possible to use AEM along with USB qube, you just have to > disable the early hiding of USB devices from dom0. But once Qubes is > fully booted and sys-usb started, you get the full USB qubes protecion. > > > So this is where the what fits into you "security model" What are > > you more concered about. I assumed we had to choose between aem vs > > sys-usb? For people travelling with laptops in strange places > > where physical compromise is more likely aem is a good option. > > Some people would prolly not just buy a new laptop but know when to > > destroy theirs too lol. > > The only trade-off for AEM regarding USB devices is that the USB stick > you buy to install AEM on could be compromised already (straight from > the factory, or intercepted & infected during shipping). And since you > need to plug it directly into dom0 in order to perform the install, it > could exploit USB or filesystem drivers and gain control of dom0. > > So it is kind of a trust-on-first-use scenario for the installation > step only. > > > Cheers, > Patrik > > > [1] https://blog.invisiblethings.org/papers/2015/state_harmful.pdf > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJZpZpBAAoJEFwecd8DH5rlE4gP/3WFFUmqb8ChECEgfgKeDRlz > VdLWPVuG8mnIr8SWeSCbkmgTA4fz1F6BWCv4puTDpADMc/HyXzrxkl6hxPBnSgdb > Rr01lGXkAda0EcSkhEUcuViCTed+yMf2y7gSJdJJrFnWiomeNft3Bq4KlpqA3t86 > r9oofbkH161bGsED8NdTlLFz+uE68gZq7D/ba+xWWJnBM/YT/lWdI29wwZhoJgPn > x6sm4BNE5szbBOwFfV5JXAtCQ8E9K4bF0M8Frvh7DUAa3MsZim3iOmgmavo86Mbm > hLkjN/N4ujxKd3n6YZuA4tqgx4UOxpQWET8jHTMxgHuVd2Dwt6jpl7Uic+3PXoXt > zmoj4BLLhC3vY+8ghPEY7TYNViYCAmAe2LcrNxI4nfUxihLvttR9Nnfut6ENqvDj > oIxRDiDRCWA/ZyC7I9C1ZPiFZ1Jyzy34aFfVF6YCESSvnfI+xGn7XFs+EpVunmiA > jnSxQJTK2Y5Pqh8SLWuMGNPEGr7MF/ekKmIlepn372ftL++2D04kuHvKzn9ZQdun > rC3v7yGuFHHca6Cakj4ks9q4cZ012g2Ch6hE2S8WcTZkEbeequMNEtGYT+9BuWpr > GlLmg5EffaMBxKP6WZuiv6okXyJnVCdBctpxC3qmTeRX4pTn4eaQsr4iXbCkfRnV
Re: [qubes-users] Options for securing /boot
On Thursday, September 7, 2017 at 9:15:31 AM UTC-4, cooloutac wrote: > On Tuesday, August 29, 2017 at 1:09:36 PM UTC-4, Leo Gaspard wrote: > > On 08/29/2017 04:01 PM, cooloutac wrote: > > > On Monday, August 28, 2017 at 6:36:08 PM UTC-4, Leo Gaspard wrote: > > >> Just encrypting /boot would bring little, as it would still be possible > > >> to modify the unencrypted part of GRUB (that decrypts /boot) to have it > > >> overwrite the /boot with malicious kernel images (or even to not use the > > >> ones provided). > > >> > > >> The options I know of are (from IMO strongest to weakest): > > >> * AEM, for knowing when someone tampered with /boot > > >> * SecureBoot, for restricting the allowed-to-boot images (I don't know > > >> about its ease of use with qubes, though) > > >> * locking your bootloader with a password and disallow external boot > > >> > > >> I'd think having all these protections at the same time would be best, > > >> using secureboot mostly to avoid having to ditch the laptop after AEM > > >> says it's no longer trustworthy (because it may stop the attacker before > > >> it can even make the laptop no longer trustworthy). > > > > > > secureboot can do more then restricting boot images, it can restrict > > > unsigned drivers too. Thats the part Joanna doesn't like because she > > > does not trust who will maintain the list of signed drivers. I say I'm > > > already putting just as much trust into alot of other things like my > > > banks ssl cert when connecting to my bank account. > > > > > > We are already trusting everything coming from upstream when we update... > > > > Well it can, but the issue with secureboot I remember reading about in > > the AEM post [1] is that it assumes no security vulnerability in all the > > bootchain (which could be used to trick eg. grub to run another image > > than the one you expect it to), while AEM only assumes no security > > vulnerability in the TPM. > > > > That's why I was putting secureboot forward only as a limited way to > > prevent malicious modifications, in parallel with AEM, that would still > > be used as a more secure way of checking secureboot worked correctly. > > > > [1] https://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html > > well after hacking teams bios exploit was said to be stopped by secure boot > it became a big target last year. there has been a couple exploits for > windows, which have all been patched. But None of them relate to linux at > all. Although nothing is 100%, nor will there ever be. I believe the one exploit had to do with driver test signing in win10, another was leaked keys. Neither would affect a linux secure boot. -- 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/967af6a4-edee-436b-98ec-c817a6380292%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
On Tuesday, August 29, 2017 at 1:09:36 PM UTC-4, Leo Gaspard wrote: > On 08/29/2017 04:01 PM, cooloutac wrote: > > On Monday, August 28, 2017 at 6:36:08 PM UTC-4, Leo Gaspard wrote: > >> Just encrypting /boot would bring little, as it would still be possible > >> to modify the unencrypted part of GRUB (that decrypts /boot) to have it > >> overwrite the /boot with malicious kernel images (or even to not use the > >> ones provided). > >> > >> The options I know of are (from IMO strongest to weakest): > >> * AEM, for knowing when someone tampered with /boot > >> * SecureBoot, for restricting the allowed-to-boot images (I don't know > >> about its ease of use with qubes, though) > >> * locking your bootloader with a password and disallow external boot > >> > >> I'd think having all these protections at the same time would be best, > >> using secureboot mostly to avoid having to ditch the laptop after AEM > >> says it's no longer trustworthy (because it may stop the attacker before > >> it can even make the laptop no longer trustworthy). > > > > secureboot can do more then restricting boot images, it can restrict > > unsigned drivers too. Thats the part Joanna doesn't like because she does > > not trust who will maintain the list of signed drivers. I say I'm already > > putting just as much trust into alot of other things like my banks ssl cert > > when connecting to my bank account. > > > > We are already trusting everything coming from upstream when we update... > > Well it can, but the issue with secureboot I remember reading about in > the AEM post [1] is that it assumes no security vulnerability in all the > bootchain (which could be used to trick eg. grub to run another image > than the one you expect it to), while AEM only assumes no security > vulnerability in the TPM. > > That's why I was putting secureboot forward only as a limited way to > prevent malicious modifications, in parallel with AEM, that would still > be used as a more secure way of checking secureboot worked correctly. > > [1] https://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html well after hacking teams bios exploit was said to be stopped by secure boot it became a big target last year. there has been a couple exploits for windows, which have all been patched. But None of them relate to linux at all. Although nothing is 100%, nor will there ever be. -- 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/e7436627-706d-4d12-9230-54bc456d1ee5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
