-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2017-03-04 06:35, sm8ax1 wrote: > Hi, > > I just installed Qubes yesterday and wanted to share my thoughts and > some issues I ran into. > > Table of Contents > 1. Use Case / Thanks > 2. Minor issues with manual partitioning and assigning mountpoints > 3. First-boot dialog > 4. NetworkManager applet didn't start the first time > 5. Modifying /etc files in template-inherited VMs persistently > 6. Screensaver blacks screen but doesn't turn off the backlight > 7. sys-firewall uses much more RAM than it should have to > 8. Encrypted /boot partition support > > First, I want to thank the developers. I've used Xen with QEMU and GTK+ > on other Linuxes before, so I'm familiar with some of the concepts. I > was trying to accomplish basically what Qubes did, but it was a real > pain to manage, the actual security of the whole system was > questionable, and even simple tasks like pasting text or transferring > files were a pain. You guys did a great job with Qubes. It's the OS I've > been waiting for. >
Welcome, and thank you for the thoughtful and organized feedback! > I learned about it a long time ago, probably around the time it first > came out, but I didn't think about trying it until it was featured on > the Tor blog and I learned about some new features. (For anyone who's > interested, I had a thoughtful, though theoretical, debate with another > reader about the some of the design choices around Qubes: > https://blog.torproject.org/blog/tor-heart-qubes-os#comment-229452) > > The installation was pretty easy, but I ran into somewhat of an edge > case that held me up a little. I did my partitioning manually, and kept > the same GPT (and protective MBR) that was already installed. > > BIOS Boot Partition (1007K) - out-of-alignment filesystemless partition > that allows GRUB to embed itself > EFI System Partition > /boot partition > encrypted main partition with LVM > root > swap > > All good. Here's the issue. I thought I would "help" the installer by > creating a BTRFS LV for the root filesystem. It showed up in the > installer with a weird name like "btrfs.XXX" (where X is a digit that > changed on each reboot), and it didn't have the logical volume name in > the subtext like my swap LV did. I was typing "/" into the mountpoint > field, but instead of moving the partition up to the > to-be-assigned-a-mount-point group (above the list of available > partitions) when I clicked away like /boot and /boot/efi, the "/" > disappeared and the partition stayed put. I didn't think anything of > pre-formatting the LV with BTRFS because it was okay for all of the > other partitions. > > I worked around it by removing the filesystem from the LV (zeroing it > out), and then the installer finally allowed me to have a new BTRFS > filesystem created on the LV and a mountpoint assigned. I think at some > point I read in the documentation that the root filesystem MUST be newly > created, but it would have saved me a lot of time if the installer had > just told me that. Overall I'd say it did alright for an LVM-on-LUKS > with BTRFS installation though. > Possibly related and/or helpful links: https://www.qubes-os.org/doc/custom-install/ https://github.com/QubesOS/qubes-issues/issues/2340 (I've added a link to your post.) > The first-boot options dialog could have explained the options a little > better, or they should be explained in the documentation. For example, > the option to proxy all applications and upgrades through Tor, I > selected it because it sounded like what I wanted, but I didn't really > understand how it would affect the networking VM hierarchy or whether I > could still create unproxied VMs. I left the USB VM (sys-usb) option > unselected because I wasn't sure how reliable it would be, I don't have > an IOMMU anyway, and I don't connect a lot of random USB devices to my > computer, but I would like to try the feature in the future. All along I > was thinking "Can I change my mind later? Am I stuck with these > decisions for the rest of my life?" > We plan to implement explanatory tooltips to help with this: https://github.com/QubesOS/qubes-issues/issues/2211 (I've added your comments and a link to this post.) > Next, and this is the biggest one, the NetworkManager applet in sys-net > didn't start the first time, so I spent an a lot of extra time tinkering > with it and researching the problem until I found a bug report that > described the exact problem I was having. All I had to do was restart > sys-net, but it would have saved me a lot of time if it had started on > its own the first time. > Was it this one? https://github.com/QubesOS/qubes-issues/issues/2293 > I wanted to setup MAC address spoofing on my wireless interface too, so > I modified /etc/NetworkManager/NetworkManager.conf in sys-net, but when > I restarted it my changes were gone. I read that I have to make changes > in the TemplateVM itself (fedora-23) for them to be persistent, but the > problem is that I don't necessarily need all VMs to have this change. > I'm still not sure of the correct way to make changes to a single VM > that inherits from a TemplateVM. > On MAC anonymization: https://www.qubes-os.org/doc/anonymizing-your-mac-address/ On TemplateVM persistence: https://www.qubes-os.org/doc/templates/#important-notes On making directories persistent without making the changes in a TemplateVM: https://www.qubes-os.org/doc/bind-dirs/ > Also, the screen saver doesn't turn off the display backlight like it > did on my old OS on this machine. Rather, the screen goes black but the > backlight is still on. I've seen other machines do the same thing, but I > know the hardware and drivers support turning off the backlight on this > machine if I can figure out how to configure it. I'm really hoping it > doesn't involve recompiling the kernel or anything like that. > This sounds like a hardware-specific issue. It might be worth asking about this in a separate thread (in which you give your hardware specs). But first, if you haven't already done so, I recommend investigating it as an upstream issue. > When the Qubes VM Manager came up, my first thought (after noticing how > nice it looked) was "1400MB of RAM for a firewall? Really?" It's now at > 723MB, but still, I have a feeling something like DSL or Alpine Linux > could do the same with less resource consumption (and better hardening, > as an added bonus). > The Qubes memory manager (qmemman) daemon automatically and dynamically reallocates available memory to all running VMs. If a small number of VMs are running relative to your total system memory, it will appear that they're using large amounts of memory. However, that memory will simply be reallocated to new VMs when you start them. So, it's not that sys-firewall *requires* that much memory. That's simply how much memory qmemman has given it at the moment, since the memory is not needed elsewhere. More information about qmemman: https://www.qubes-os.org/doc/qmemman/ > Lastly, something I lost from my old setup was an encrypted /boot > partition[1]. It used GRUB_ENABLE_CRYPTODISK=y so that Grub itself could > unlock the /boot partition run the kernel and early userspace, which > could optionally do some authenticity checks (e.g. verify the bootloader > was not modified)[2], and then ask for the main partition password. > Although not perfect, this helps protects the kernel and early userspace > from tampering and mitigates certain other offline attacks. Are there > any plans to support something like this on Qubes OS in the future? > Yes: https://github.com/QubesOS/qubes-issues/issues/2442 > [1] > https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_.28GRUB.29 > [2] > https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#mkinitcpio-chkcryptoboot > - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYu+3wAAoJENtN07w5UDAweSIP/0gSLrQx1C+AIMuRSal+TVDi WZTJA9/tmODetes4q6EDD2WqlnTIYB5J/aFYmt8oPvqZ3vR+a7MT5msX7X+QX1cF 0IkEPlT+pXu6tezRiUeJf6kRbvSP6uv1WA8aX8rmR0mQ5WhFQVASsCHeXol6vG5T 9C1892RycUkf5KykkBnS1kwiOofAvErQrYtweBitACuUfuDB5/nOsdYxipqGfKbt xETjsvy404TtxwAzgXdmUvTutFynaJq87C4RtnsQgac6Atrz2256BfpFiVmVSaRU 6cgN9LLdiPNJoT/qo5nOGTMM+8fdECKq96s1hnqv5lcoJP4GsA24C4mrZWBjoJha gOdn1xF303n3e0aLwsCoIX768n8BykP1huUJUtQgHzJ+3VvQMODA9lXweehOQ/Mg S3VzCLjhmmd3mj7umQzkzMNzmOJCnhf4pNJlsbnFEHMuVPfgaKyI1E058s9VzWQm hRuFy7OPx5GU7NpRDdzsA/yz/LAgcX/r2x/XLni1dSLIECYo+QMTXmQC16Y9RNMp FY+EYmLeevXdZjwT09iosIfTXBWaxFzp+EO0o0FjduHh0OYl7PHXnCbFknLKYbuS 2BpRKQP8PfXw+mtViHMDH5jxLUF7f9Df6TZti/QovlKeslyRNoRmxDrxx8MtdO86 O5Z4/dXxTPHYQHlBQ8eK =79m1 -----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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8f8515a5-fbfb-3382-8290-052c8d1973b8%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
