Andrew David Wong:
> 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.)
Thanks, I read the custom install page prior to installing, but I was
unaware of #2340.
To be honest, when I decided I wanted BTRFS, I just sort of assumed that
guest disk images were logical volumes to begin with. The custom install
page mentioned LVM in every scenario, so I thought it was necessary for
that reason. And the Xen wiki repeatedly mentions that logical volumes
are faster than image files on any kind of filesystem. It was, however,
suspcious when the custom install page said "-l 100%FREE" for the root
LV. I guess that's what I get for assuming.
Are there any plans for hooking Qubes up to the LVM in this way? LVM
itself supports block-level rw CoW snapshots, and the Xen project
strongly recommends it over image files.
And as a final thought, it really wouldn't be that hard for Qubes to run
`chattr +C $file` when a new image file is created (though CoW is
reenabled if you take a snapshot, according to #2340). Note that if you
want to do this after the fact, you have to recreate the file (setting
+C on a non-empty-file is undefined).
mv file.img file.img.bak
touch file.img
chattr +C file.img
cp file.img.back file.img
rm file.img.bak
>
>> 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
Yes, and #2537 referenced by #2293 in particular. I didn't have to mess
with service files or the Services tab at all fortunately, I just had to
restart sys-net.
>> 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/
That's more or less what I read on other sites. I think we should
consider putting a Big Fat Warning on that page saying that your changes
will be lost on restart if the VM belongs to a template, or you could
easily leak your real MAC address by accident.
>
> 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/
Thanks. It sounds like bind-dirs.sh is just what I need!
>
>> 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.
I found a partial solution to this. Running "xset q" showed that DPMS
had various timeouts set, but was disabled. I opened the Xfce "Power
Manager", switched to the "Display" tab, and then toggled "Display Power
Management" off and on again. Then, "xset q" showed DPMS enabled. I
guess it just needed a poke, sort of like the NetworkManager/sys-net
issue. I'm still having trouble getting all of timeouts right, at the
moment it puts the screen into standby (backlight off) but at some point
it will come back on with just the blank screen. I'll look it up and
play around with it and see if I can figure out what's wrong. It is
probably an upstream issue but hopefully worth mentioning here.
https://wiki.archlinux.org/index.php/Display_Power_Management_Signaling
http://shallowsky.com/linux/x-screen-blanking.html
>
>> 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/
Thanks. I haven't read the whole article yet, but it makes makes a lot
more sense now.
>
>> 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
That sounds almost like a wontfix. "Imperfect therefore pointless" so to
speak. It is the usual reaction to encrypted /boot, in my experience. We
had to go through a fairly detailed list of scenarios that it would and
would not protect against before it even made it to the Arch Wiki.
It is true that real firmware-level protection like secure boot would be
superior in detecting bootloader tampering, and I strongly encourage the
developers to work towards enabling it for machines that support it, but
that's not possible for everyone, particularly those with a BIOS or
without the ability to enroll their own UEFI keys. Even that isn't
perfect if the installed OS has ever had access to the signing key,
meaning offline kernel/initramfs updates (from a bootable drive) would
be necessary.
The point is that it's far easier for someone to build a malicious and
stealthy payload into /boot/vmlinuz or /boot/initramfs.img compared to
the first track (first 440 bytes) of the hard disk, where Grub stage1 is
located, or the EFI Boot Partition (or post-MBR gap) where stage2
(core.img) is located. Apart from the payload size restrictions, you
have Real Mode and the lack of system calls, hardware drivers, and
dynamic linking (to an extent) to contend with.
Storing /boot on an external drive is already possible as with any OS.
The only work to be done there is a friendly GUI that helps the user do
it. And if you accidentally forget to insert the drive before booting,
or you get your BIOS boot order wrong, then you're booting from the hard
disk anyway, so that's not perfect either.
I guess we'll just have to wait and see if anything comes of it.
>
>> [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
>
>
>
-------------------------------------------------
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!
--
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/3681f5fb-1138-5b94-6b62-b1a63b29441c%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.
