Re: [qubes-users] wipe released diskspace of a disposable VM's
As to the first question: with qubes 4.0 it is a bit difficult to effectively wipe free space in the default thin pool. One can create a thin volume and write to it until the thin pool reaches some saturation level (99.5%), then hit that volume with blkdiscard before invoking lvremove. Because you should not go to 100% the user may still be rolling the dice. Lvm doesn’t like hitting 100% and one can permanently corrupt the system if you fill the lvm all the way. It’s possible the lvm tool chain in 4.1 may have more capabilities once dom0 is on a much more recent fedora version. It’d also be nice to have dom0 in a different pool than the templates/VMs...to reduce catastrophic failures. B -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6fae11a3-cfb8-4318-908b-76d3f2750387%40googlegroups.com.
Re: [qubes-users] wipe released diskspace of a disposable VM's
Disposable VMs were not developed with anti-forensics in mind (e.g. no protection in jurisdictions where you can be forced to hand over your drive password). That being said... In 4.0 (updated) qubes now calls blkdiscard on volumes being removed before invoking lvremove. If you happen to use a SED SSD and you have manually enabled discards through all layers to the physical drive, then, depending on the manufacturer implementation, the data from a shutdown disposable VM might not be recoverable even with your disk password. No guarantee but I recommend enabling discards all the way down. After some forensics experiments, I put together a rough-at-the-edges bash script that does a rather good job of ensuring the volumes are not recoverable. It creates an over-provisioned lvm volume In the current pool, overlays a new randomly keyed luks volume on top, makes that into an lvm pv, layers lvm vg and finally an lvm thin pool on top. Adds that new thin pool to qvm-pools, copies templates and VMs there, temporarily modifies the global default pool setting (needed to be sure *all* volumes related to the VMs were in the ephemeral pool) and starts up some sessions. I need to make it a bit more flexible but it served my need. Once all started VMs are shut down, the script unwinds all the storage layers. Since the luks layer was random keyed, that data is gone once unmounted. Been meaning to clean it up and share at some point. Brendan -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f6b7c6e3-6f8d-473a-9dc5-5fdf91cbf3b7%40googlegroups.com.
Re: [qubes-users] wipe released diskspace of a disposable VM's
josefh.maier via qubes-users: Hello list, I heard that a Qubes-user was forced to hand over the Qubes-password, and that a forensic examiner was able to restore artifacts of a deleted disposeable form the harddisk... Is this story possible? And what's the best aprroach to wipe diskspace used before by a disposable VM after that VM is closed? Thank you! Regards, Joe Isn't there an option in VM settings called "Keep DispVMs in memory" or something like that? I'm assuming its purpose is so that dispvm contents are never written to disk in the first place. It consumes more ram so it might not be exactly what you want, but it's worth trying. Depending on your situation, you might be able achieve what you want by regularly wiping free space. There are tools for ext4 that do this. Maybe there are similar tools for Btrfs or LVM volume groups. It's probably not a great solution, because depending on the filesystem some data may be released and reallocated, but not overwritten, in between wipes. I'm not aware of any tools that transparently overwrite free space at the moment the file is deleted. Maybe you could write your own storage pool configuration that stores DispVM images in a special place (partition, loop device, LV, whatever). Then, you can wipe the entire thing (when no DispVMs are currently running), which is much more reliable than wiping free space. Or, you can encrypt it with a random key at boot, which is never written anywhere. If you're up to the task, it would definitely be possible to do this by writing a storage pool *driver*, but much more work. https://www.qubes-os.org/doc/storage-pools/ https://github.com/QubesOS/qubes-issues/issues/904 - This free account was provided by VFEmail.net - report spam to ab...@vfemail.net 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 qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/09275b10-a64e-1aec-b188-435a783b2107%40vfemail.net.
[qubes-users] Re: Fwd: Audio not working: "snd_hda_intel: No response from codec, resetting bus"
Claudia: [...] So, to recap what I've found so far: Fedora 25 live cd: works Qubes without Xen: works Qubes with Xen: codec probe error Qubes with Xen, VT-x & VT-d disabled: codec probe error Qubes with Xen, single_cmd=1: codec detected, but no sound [...] Just following up. Audio works flawlessly out of the box in R4.1-20181013 with kernel 4.19.76-1. Didn't work in R4.0.2 with 4.19 or even 5.0 kernels even after days of tinkering with it. So it could be due to the Xen version (4.8 -> 4.12), Fedora userland version (25 -> 29), or changes to qubes-specific code/config (4.0 -> 4.1). I was hoping to get it working in stable, but I'll probably just keep using 4.1 for now. - This free account was provided by VFEmail.net - report spam to ab...@vfemail.net 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 qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/11cbb4e3-25fb-f795-ebdf-f049b9ff3d1c%40vfemail.net.
[qubes-users] Dual booting Qubes and Qubes?
I'm wondering what the best way is to go about installing two instances
of Qubes 4.1 on the same machine, which are more or less independent of
each other.
It's fairly easy to dual boot different OSes because they each have
their own EFI directory, e.g. /boot/efi/EFI/{qubes,fedora,ubuntu}, but
what happens when you want to dual boot two of the same OS? (Or two
different releases of the same OS?)
My original thought was to just give each one its own directory in
/boot/efi/EFI/, but the /boot/efi/EFI/qubes/ path seems to be hard coded
somewhere, probably either in the grub2-efi package (which installs a
precompiled efi binary to that directory) or in a grub2-install hook
somewhere. Not sure which of those methods Qubes uses. At least, I
couldn't figure out any way to persistently change the name of the EFI
directory. Of course you could make your own directories by copying the
files. e.g. /boot/efi/EFI/qubes{0,1}/, but when it updates (or you
reinstall one of them), they would both try to install to
/boot/efi/EFI/qubes/ again. And you'd have to manually change the path
each time with efibootmgr.
My other thought is to give each instance its own EFI partition, /boot
partition, and root partition. efibootmgr allows you to specify which
partition, by index, the path resides on for a given boot menu entry.
However it's technically out of spec to have more than one EFI partition
on the same device and I don't know if UEFI implementations know how to
handle multiple EFI partitions correctly. Additionally, since EFI
partitions all use the same magic UUID, the OS wouldn't know which one
to mount at /boot/efi, so they could easily get mixed up. I guess you
could reconfigure /etc/fstab to mount based on partition number, e.g.
/dev/sda1, /dev/sda4, but that brings its own set of problems.
Nevertheless it seems like this might be the best option.
Another option is to uninstall grub on one of them, so that only one
instance ever touches /boot/efi/EFI/qubes. And then write a custom
grub.cfg with a menuentry for each instance. However I don't know how
you'd prevent the installer ISO from trying to install a boot loader
initially. A major reason for having two separate instances is so that I
can reinstall one or the other from ISO without much trouble. So I don't
want the installer clobbering my boot loader every time. Additionally
you'd have to manually modify your grub config with the new UUIDs every
time you reinstall.
I'm still new to UEFI systems so I don't know if any of these would
work. Anyone have any ideas or insights? (Funny how UEFI redesigned the
entire boot process, and it's still just as messy as it was before.)
-
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/a87e590b-7cd8-e081-58bc-1bf7c61d0a8c%40vfemail.net.
Re: [qubes-users] to use different OS
'marioski' via qubes-users: Hi, simple question: Can i choose different OS (Windows, Linux, MacOS) in Qubes OS? as if I had a trial boot on my pc reserved for Qubes OS thanks You mean dual booting? On UEFI systems, Qubes 4.0 will install the Xen loader and create a UEFI boot menu entry for it. So you can choose which OS from the UEFI boot menu. On legacy systems, it will install grub and add entries for other OSes using os-prober, just like other Linuxes. The installation guide also has instructions for installing to a USB drive, which is completely portable. - This free account was provided by VFEmail.net - report spam to ab...@vfemail.net 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 qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/65e979c6-0109-e03d-5694-2f5441f7ea97%40vfemail.net.
Re: [qubes-users] How to open Systemgui
Myros: > Hi, > > I installed Win10 and that worked without a problem, but then i installed > the windows tools on it, and now nothing opens at all. i think that has to > do with seamless-mode... (i forgot to give the vm internet, so it was > unable to download certain things) > > So not only for my win-vm, how can i open the system-GUI of an installed > OS, like not only a single program, but the whole VM? > Sometimes checking the debug mode box will give a display. -- - don't top post Mailing list etiquette: - trim quoted reply to only relevant portions - when possible, copy and paste text instead of screenshots -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a681b20f-b936-9ddd-d6d8-2ccdb2dfc5c4%40danwin1210.me.
