Open qubesuser opened 9 years ago
marmarek
commented
9 years ago Some relevant photos: https://twitter.com/rootkovska/status/541980196849872896 https://twitter.com/rootkovska/status/650732336330489856
Anyway this is something we consider in "Untrusted Storage Domain" design page 33.
qubesuser
commented
9 years ago I think just shredding like in the screenshots is potentially insecure (against someone obtaining the full disk encryption password), since the SSD or hard disk might have reallocated the blocks, and the filesystem might have done that as well (e.g. if using btrfs).
With XTS blocks are encrypted depending on the disk position, but one could in principle try all encryption positions on all raw disk blocks not part of files and then use entropy, compressibility, presence of long ASCII strings, etc. to guess at the correct plaintext.
Anyway this is something we consider in "Untrusted Storage Domain" design page 33.
Yes, that specific design for an untrusted storage domain would solve this issue too (assuming there is a way to securely destroy the per-AppVM keys), although they actually seem orthogonal in general.
One could implement an untrusted storage domain with the same key for all AppVM, as long as the decryption is done in dom0 as opposed to directly connecting the AppVMs to the storage domain and forward secrecy is not a goal.
An untrusted storage domain threat model also has other requirements like the need to defend against active manipulation, which means that something like the LUKS XTS FDE is not enough, and you'd also need to authenticate everything with a Merkle hash tree of all the disk sectors and then authenticate the root using a secret not shared with the untrusted storage domain (otherwise the storage domain can replace sectors with older encrypted versions) and probably generate and store a new random IV for each encryption to prevent leaking data correlation over time to the untrusted storage domain (with XTS or CBC ESSIV if you write A then B then C to the same sector, then the storage domain would know whether A = C or not because the IV/tweak and thus the ciphertext is the same).
marmarek
commented
9 years ago One could implement an untrusted storage domain with the same key for all AppVM, as long as the decryption is done in dom0 as opposed to directly connecting the AppVMs to the storage domain and forward secrecy is not a goal.
The point about Storage Domain is that dom0 would not touch VM data at all.
Regarding data authentication - yes, it is covered in that design. We haven't decided about precise implementation used for that - one candidate is dm-verity, but maybe there are alternatives.
Some subset of above - anti-forensics data handling - is considered for DispVMs - #904 . There is a chance that we'll implement it for R3.1.
qubesuser
commented
9 years ago The problem of dm-verity is that it seems to currently have no write support, which means it would obviously not work for defending mutable AppVM storage against a malicious storage domain.
Not sure if there is any alternative, it's possible that there is no easier way to do this than doing custom development on dm-verity (which is not so trivial because it needs to be crash-proof).
BTW, directly attaching AppVMs to an untrusted storage domain can be problematic, because a malicious or misconfigured AppVM could leak all its data by simply not encrypting anything (and viceversa the untrusted storage domain could send arbitrary plaintext), creating a very high-bandwidth covert channel that can be accessed even by someone that can only read/write a snapshot of the storage.
marmarek
commented
9 years ago On Thu, Oct 08, 2015 at 01:11:27PM -0700, qubesuser wrote:
BTW, directly attaching AppVMs to an untrusted storage domain can be problematic, because a malicious or misconfigured AppVM could leak all its data by simply not encrypting anything (and viceversa the untrusted storage domain could send arbitrary plaintext), creating a very high-bandwidth covert channel that can be accessed even by someone that can only read/write a snapshot of the storage.
When the AppVM is compromised, it means that the data there is no longer safe. The whole point about isolation is that only one particular VM would be affected. In case of cooperating compromised domains, x86 architecture provide sufficiently enough covert channels. Yes, some of them have lower bandwidth, some higher, but still - currently it's hard to solve, at least on on x86. I guess, in most cases, the most precious data is quite small anyway (keys, etc).
Regarding storage domain sending arbitrary plaintext - it shouldn't be a problem as long as AppVM properly verify the data. And when not, it's already game over for that VM.
And generally the whole idea about Untrusted Storage Domain is to take some more pieces out of TCB. Currently we need to trust disk controller firmware (because it can effectively own dom0 using DMA) and assume block backends are bug-free. We want to take those parts out of TCB. Yes, some details needs to be sorted out, but in current design shape, it will not be worse than the current approach (where the physical storage handling is basically ultimately trusted).
Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
marmarek
commented
9 years ago I'm closing this one as a duplicate of #904. For "Untrusted Storage Domain" there will be a separate ticket.
andrewdavidwong
commented
8 years ago @marmarek: I can't find an existing issue that tracks per-VM encryption. This is the closest one. Should we re-open this issue to continue to track that, or open a new one?
DemiMarie
commented
6 years ago What could I do to implement this? For swap devices, LUKS should be up to the task.
DemiMarie
commented
5 years ago Libvirt provides an API for storage encryption using LUKS. I could try to make a PR, but I would not be able to test it locally.
tasket
commented
5 years ago How much overlap is there between this request and current storage pool feature?
IMO, they seem mostly the same.
marmarek
commented
5 years ago It's definitely possible to implement this as a qubes storage pool driver.
As for libvirt API for that, we've looked at it before and actually considered to use that, instead of our own storage pools implementation. But in the end rejected because of various limitations. For example it doesn't support LVM thin provisioning (only non-thin LVM), or btrfs reflink copy (copy-on-write). Those (and other) limitations are the reason why we have our own storage pool drivers.
And it looks like libvirt storage encryption API is can be used only for volumes managed by libvirt storage pools, so it's useless for us unfortunately. It's a pity, because that encryption API already have for example ephemeral secrets - perfect for volatile volumes.
DemiMarie
commented
5 years ago Could we instead improve the libvirt implementation? We have a bunch of patches to libvirt anyway.
On Sat, Jan 26, 2019, 6:44 PM Marek Marczykowski-Górecki < notifications@github.com wrote:
It's definitely possible to implement this as a qubes storage pool driver.
As for libvirt API for that, we've looked at it before and actually considered to use that, instead of our own storage pools implementation. But in the end rejected because of various limitations. For example it doesn't support LVM thin provisioning (only non-thin LVM), or btrfs reflink copy (copy-on-write). Those (and other) limitations are the reason why we have our own storage pool drivers.
And it looks like libvirt storage encryption API is can be used only for volumes managed by libvirt storage pools, so it's useless for us unfortunately. It's a pity, because that encryption API already have for example ephemeral secrets - perfect for volatile volumes.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/QubesOS/qubes-issues/issues/1293#issuecomment-457875971, or mute the thread https://github.com/notifications/unsubscribe-auth/AGGWB9K_gCzQT__E29ZiEFmETQRCMsC9ks5vHOhxgaJpZM4GK2ny .
marmarek
commented
5 years ago I think doing what we need there in C would be much more (and more error-prone) work than in python.
brendanhoar
commented
5 years ago [A note from the peanut gallery...]
It's unclear to me to what degree Qubes's architecture incorporates (or should incorporate) anti-forensics, in addition to the core privacy and exploit-resistance features. If anti-forensics is a focus for the development team, then I suggest that a staged approach be taken to VM-specific encryption.
In particular, start with resolving issues automatically, such as unintended data permanence. That is, address issues that the user does not have to interact with and which guarantee some level of confidence that data not meant to be kept is not kept. This also gives users under certain threat models a form of plausible deniability. Perhaps the user already believes this is being done, but it is not yet being done, e.g with dispVM data?
The dom0 swap volume (perhaps also later: storage domain swap volume) should be mounted with a random key generated via xen or dom0 at every startup, which would (obviously) be discarded on shutdown.
At the domU VM, level, start with system-managed "opportunistic" encryption. All volatile volumes and/or volumes which do not need to be kept between VM restarts should be encrypted with random keys generated via xen, dom0 or a future storage VM, and these keys are discarded at VM shutdown. This should include: a) swap volumes for linux VMs; b) the volatile changes of the non /rw volumes on template-based VMs; all volumes for disposable VMs.
On a Qubes volume removal/deletion and/or on a full Qubes VM removal/deletion, shred the non-encrypted volumes by default (perhaps the opportunistically-encrypted ones as well, though that may be redundant for many use cases). The "shred" implementation might have a couple of different approaches, based on underlying hardware, e.g. HDD vs. SSD. E.g., the trust in the SSD's drive-reported Trim capabilities may be a factor. This is usually where I hear what a S#!*-show the SSD firmware world is, but there are pitfalls in areas of things like partition alignment as well that can make data clearing incomplete.
On SSDs, dom0 and domUs perform a full trim @ startup and on shutdown of unallocated space on all mounted volumes from their perspective, including dom0's mounted storage pool(s) (if applicable?). For HDDs, a dom0 shutdown shred would have to be made optional, due to the time consuming nature of this on HDDs.
These above steps (0 through 3) would give some confidence that data not meant to be retained is not retained. With the LUKS layer (which uses the logical block number in the XTS mode) above the drive's FTL, and with the window of time from trim to actual block erase being reasonably small, reconstructing trimmed data that has not yet been erased post-trim would still be a rare event (again: threat model), even if the LUKS key were made available to the attacker.
Only then design/implement features that are user-managed. Only then would the deeper complexities of uses cases, threat models, etc. come into play.
Summary: perhaps one problem to solve is one that a lot of users may already have assumed was already solved: that data that they have deleted or that they did not intend to keep is still stored on their system.
Brendan
PS - I wrote this up after reading several linked issues that were closed due to "duplicating this issue", but what I interpreted them to cover likely other issues, not central to "per-vm" encryption. Anyway, at the worst, I hope reading the above was not a waste of your time.
andrewdavidwong
commented
5 years ago PS - I wrote this up after reading several linked issues that were closed due to "duplicating this issue", but what I interpreted them to cover likely other issues, not central to "per-vm" encryption.
FWIW, I'm always open to reopening and unmarking issues as duplicates if there's a good reason to do so, but since I don't know exactly which other issues you read or why you believe they may not really be duplicates, I don't know which ones should be reconsidered.
ffsec
commented
5 years ago Good to see there is movement on this topic after such a long time. I also looked into this topic recently regarding Qubes 4.0 and figured, it wouldn't be a problem to implement this feature. There are a few things that need to be thought about though:
@marmarek: Since there were already considerations using libvirt, etc., is there already a concept/plan on how to implement this feature yet (even when incomplete)?
brendanhoar
commented
5 years ago FWIW, I'm always open to reopening and unmarking issues as duplicates if there's a good reason to do so, but since I don't know exactly which other issues you read or why you believe they may not really be duplicates, I don't know which ones should be reconsidered.
Thank you for the thoughtful response, Andrew. Examples, within the context of the current thread's open Issue (Per-VM encryption) covering a feature that the user manages for selected VMs:
tasket
commented
5 years ago @marmarek I asked because users appear to think they can't currently encrypt their VMs separately.... when they can. The easiest way is probably to use the Veracrypt GUI and format the volume as Btrfs, then setup a pool in Qubes. Of course, automating this would be a nice feature.
@brendanhoar Shredding is probably not a realistic feature for Qubes. On SSDs its promising too much and on HDDs its too slow. The clear choices for volatile storage are either in-RAM (like TAILS) or ephemeral encryption; the latter provides usage characteristics that are closest to a regular PC.
brendanhoar
commented
5 years ago @tasket -
Related to shredding (in particular, SSD trimming as a substitute, I agree HDD is likely too slow in the majority of situations): I want Qubes to provide SSD trimming along the entire stack as an opt-in (with warnings) during install even with the project's lack of trust in various storage devices' promises. I do have confidence in one manufacturer's implementation in this area and their DRAT/DZAT implementation (but not others) and I would like to harness the capability with these devices. But for now, I'm manually configuring automatic trim as well as throwing in sudo fstrim -av invocations at startups/shutdowns.
We both agree it would be best to automatically use ephemeral keys/encryption across the system for any volatile data or data that does not need to survive restarts, and in my preference this would be configured this way during install.
Also, thanks again for all of your contributions.
stacktrust
commented
5 years ago A couple of data points from other projects:
OpenXT uses thin-provisioned VHD files with per-VHD encryption keys and snapshots. VHD encryption was recently upstreamed to XenServer: https://github.com/xapi-project/blktap
ZFS upstream development is consolidating on Linux (via DKMS), after years of the community being divided across Illumos (Solaris roots), FreeBSD and Linux. License challenges aside, ZFS on Linux has competitive features for data integrity, low-cost live snapshots, replication and encryption.
DemiMarie
commented
5 years ago @brendanhoar which is the manufacturer whose implementation of trimming do you trust?
DemiMarie
commented
5 years ago Also, it is possible to provide secure deletion by means of periodic key rotation:
Because encryption keys are small, it should be possible to store them in the TPM, from which secure deletion should be possible.
brendanhoar
commented
5 years ago @brendanhoar which is the manufacturer whose implementation of trimming do you trust?
Short version: Samsung.
Long version:
Re-reading the recently discussed paper on SSD vulnerabilities, watching the video linked below and reviewing their comparison of the firmware changes from 840 to 850 models, there's clearly an iterative security-focused design methodology going on in-house at Samsung both in software and hardware.
One of the authors recently gave a talk at 35C3: https://www.youtube.com/watch?v=C5hLTk5MyGU Watching the talk answer some questions I had after reading their paper.
I agree with the authors about the gaps they found in Samsung products (the other manufacturers they looked at were a dumpster fire), but almost none of that was in Samsung's core OPAL implementation. The issues were in the code mapping legacy ATA PW use into the OPAL model. This is also the reason their portable drives were vulnerable, it was just a custom variation of their flawed ATA PW implementation. Samsung has addressed the s/w vulnerabilities found via firmware updates. They haven't addressed the fact that the 840 has exposed JTAG, but that's harder to do with firmware updates. :) Later models curtailed hardware exploits.
I disagree with the authors on the issue of hardware encryption giving no benefits that software encryption can't already give. I believe in utilizing both at the same time to hedge your bets: on the one hand, you may trust the open source implementation of LUKS way more than the black box of Samsung hardware (a given with this audience). On the other hand, the closed source Samsung hardware walls off one set of keys from the host OS memory which, as we know, continues to be a vulnerable area. And now with the paper, the December talk above, some additional forensics papers and with the below work by Philipp Guhring that the paper's authors leveraged in their research, we can now better understand what really is going on inside the drive.
Philipp has been trying to recover a broken Samsung 840 for several years and has continued to update his notes and analysis of the Samsung 840 firmware ( http://www2.futureware.at/~philipp/ssd/TheMissingManual.pdf ). I find the descriptions of Samsung's implementation both illuminating and very satisfying. They clearly have been doing their homework. It's almost as if one or two of their customers might even be concerned about nation-state attacks... :)
Some interesting points on the 840, which, I will reiterate, is a unit several generations old:
Remember, also, within the context of a standard Qubes config, this is all happening below an additional layer of software AES-XTS utilizing LUKS. So you have:
So...
...when you trim a 4KB block located at block 1455943 on the main ext4 volume from Qubes, which might be at drive LBA 1519943 (say the main ext4 volume is 256MB offset from LBA 0), the doubly encrypted data might not be erased for several seconds, but the correlation of that doubly encrypted data with either of those locations is gone and both values (though correlated) will be needed to recover the data in XTS mode. Yes, one could iterate through all possibilities for each flash block, but you only have so much time in normal operation of the drive before that data is erased from flash.
In terms of forensics the investigator/attacker has a choice to make:
So...that's my rationalization, er, explanation as to why I trust the Samsung Trim implementation.
tasket
commented
5 years ago @straussmaus For now I'll outline the basic steps:
Allocate a space, such as a disk partition, to hold the new pool.
Use cryptsetup or veracrypt to setup encryption (with a new key/passphrase) on the partition.
Decrypt the partition then create a filesystem there. Using btrfs is easy and probably gives you the best flexibility for the amount of effort invested, but creating a new lvm vg and thinpool is also an option.
Configure crypttab and fstab to unlock and mount the new volume (or leave the unlock and mount as a manual step taken by the user).
Use qvm-pool to configure a new Qubes storage pool to point to the new filesystem or vg/thinpool.
Migrate VMs or create VMs in the new pool, for exmaple qvm-clone -P poolname vmname newvmname.
adrelanos
commented
5 years ago We at Whonix are asked every now and then why we don't ship Non-Qubes-Whonix with encryption by default. Here are our thoughts on it: https://www.whonix.org/wiki/Encrypted_Images
DemiMarie
commented
5 years ago Systemd supports block device encryption natively via /etc/crypttab. The command line cryptsetup tool does too.
adrelanos
commented
5 years ago No opinion at this time. This may or may not catch my interest in future, unpredictably.
cm157
commented
3 years ago I will provide a $2500 bounty for anyone who can implement this. Maybe others can contribute? I am open to giving the money up front if necessary.
DemiMarie
commented
3 years ago @cm157 Volatile volume encryption is already on my task list. The volume will be encrypted in dom0 using AES-XTS and a randomly generated key. dom0 swap will also be encrypted.
cm157
commented
3 years ago @cm157 Volatile volume encryption is already on my task list. The volume will be encrypted in dom0 using AES-XTS and a randomly generated key. dom0 swap will also be encrypted.
This is fantastic news. I will send you an email to figure out how to handle the bounty.
ArtificialAmateur
commented
3 years ago
- Are all LVs of a VM encrypted or just private / volatile?
I would think private / volatile for AppVMs, maybe more for StandaloneVMs.
- Do we use a separate encryption key for each LV or do we use 1 key for all VM related LVs?
Separate key for each LV at first seems better, but what situtation would it provide more security if someone attained one key?
- Where are the master keys to each LV stored and how are they secured in particular?
This is also an implementation question im wanting to figure out. @DemiMarie @marmarek , ideas?
- Do we encrypt all VMs by default or only VMs which were created with some --encryptvm param?
I think it might be best to encrypt by default (StandaloneVM and AppVM) using keyfiles and then have an option (--encryptvm and gui checkbox) to provide a custom passphrase. I think DisposableVMs should follow #904.
It's definitely possible to implement this as a qubes storage pool driver.
I think this is the way to go using dm-crypt (cryptsetup) after volume creation.
DemiMarie
commented
3 years ago @cm157 Volatile volume encryption is already on my task list. The volume will be encrypted in dom0 using AES-XTS and a randomly generated key. dom0 swap will also be encrypted.
This is fantastic news. I will send you an email to figure out how to handle the bounty.
QubesOS/qubes-core-admin#396 will implement volatile volume encryption. It will not implement per-VM encryption, which will need to be handled separately.
Note that data written to the root volume in AppVMs and DispVMs will not be protected by this. I filed #6625 to track making root volumes default to read-only in AppVMs and DispVMs, which would cause data written to the root filesystem to land on the encrypted volatile volume. DispVM private volumes will still need to be handled separately.
cm157
commented
3 years ago This bounty is now at $3500. As mentioned, i open to idea of making this payment upfront or to mutually agreed intermediary in advance of completed work.
cm157
commented
3 years ago If a VM is not active its data should be in a secure state while at rest. Only when a VM is running should its data be in a unencrypted state. Its naive to assume you will have opportunity to completely shutdown your system prior to an attack.
Also, another plus as per recommendations from NSA the benefit of cascading two different encryption implementations should one be compromised... ie eggs one basket.
ghost
commented
3 years ago I'm working on it right now @cm157 proper UI integration and Admin API Integration in Python (the language Admin API is written in with @ function handlers), prompts for passphrase to dom0 via RPC. Can be done just technically or nice with Qt UI (Qubes Settings, Qubes Manager) GUI Checkboxes as well, so it takes a few hours longer. Would be glad to talk about your Yubikey / Nitrokey ideas to make it even better.
ghost
commented
3 years ago Since per VM encryption feature is being discussed, and even funding is available, which has the proper desires and input (support for 2FA keys, disk encryption per Qube, open to RAMDisk, probably not allergic to ISR), it would be beneficial to not just implement a proof of concept, which can be done, but neat QubesOS integration with UX in mind, even if it means a lot of Qt / PyQt, which I started to get comfortable with for some hours. https://github.com/fairlightcx/qubes-manager/tree/encryptdisk
Can this be moved from a feature that backups (and restore) somewhat templates on integration, and LUKS self-explains on storage, to an actual small project with partial up front funding? @cm157 @marmarek Semi-offtopic, I consider qubes-builder highly important to prioritize and currently building vvm_xen is really slow, the structure of qubes- and Marek's privilege as Chief of Git, deserve some rework too.
ghost
commented
3 years ago And, I would like to add VPN (or Tor) per Qube, if not per Application per Qube, to this ticket, after disk encryption is finely done, and Ramdisk maybe ISR, was at least shortly discussed.
andrewdavidwong
commented
3 years ago And, I would like to add VPN (or Tor) per Qube, if not per Application per Qube, to this ticket, after disk encryption is finely done, and Ramdisk maybe ISR, was at least shortly discussed.
I'm confused. Doesn't that already exist, and how is it relevant to this issue?
cm157
commented
3 years ago Hey Ghost, are you officially taking up the bounty? If so, would you like me to deposit the funds into escrow and if yes can you please nominate someone from the QubesOS project?
I'm working on it right now @cm157 proper UI integration and Admin API Integration in Python (the language Admin API is written in with @ function handlers), prompts for passphrase to dom0 via RPC. Can be done just technically or nice with Qt UI (Qubes Settings, Qubes Manager) GUI Checkboxes as well, so it takes a few hours longer. Would be glad to talk about your Yubikey / Nitrokey ideas to make it even better.
Yes, i would love to discuss that i will make a separate post on it tomorrow. Please note, 2FA is not a requirement for the bounty. Its just an idea. The only deliverable is per vm encryption.
valereznya
commented
3 years ago Mr. Zulla will donate the money to the first person or team who ports https://sourceforge.net/projects/isrupin/ to 64-bit and keeps an approach like randomization of binaries with XOR but elevating support to arm64 and power9, for example with https://blog.trailofbits.com/category/mcsema/ or https://github.com/zyantific/zydis instead of pin-xed2 but eventually either functional static binary translation running TorBrowser successfully, including JavaScript, or , https://github.com/ComputerSystemLab/hqemu elevated by Symbolic Execution (KLEE) or https://github.com/facebookresearch/nbref reaching the same goal with TorBrowser (Whonix) and an interpreted JIT language. We nominante @rootkovska to hold the money.
valereznya
commented
3 years ago If a VM is not active its data should be in a secure state while at rest. Only when a VM is running should its data be in a unencrypted state. Its naive to assume you will have opportunity to completely shutdown your system prior to an attack.
Also, another plus as per recommendations from NSA the benefit of cascading two different encryption implementations should one be compromised... ie eggs one basket.
We entirely concur we shouldn't hack something up, although starting with a proof-of-concept tests/AppVM_requests_pass_from_dom0_for_QubesAdmin.Storage_RPC and for mnt in mount() admin.RequestLUKS(mnt) but definitely bringing the very valueable feature of of self-reencrypting storage device (private and system of TemplateVM?), encrypted memory, selectable in Settings and in User Dialouge, perhaps even set as a default like "provides network"
If a VM is not active its data should be in a secure state while at rest. Only when a VM is running should its data be in a unencrypted state. Its naive to assume you will have opportunity to completely shutdown your system prior to an attack.
Also, another plus as per recommendations from NSA the benefit of cascading two different encryption implementations should one be compromised... ie eggs one basket.
Entirely agree this should be considered well cryptography wise, and added to the system well UI and tests/, demo impl wise. Auto Encrypt of storage and/or memory, defaults at creation, and visualiaztion with icons or a graphic in the GUI should be considered with @ninavizz, PoC for LUKS in AppVM is being done with dom0 execution or libvirt permission? of essentially sudo cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/sdb in QubesAdmin.VM.Storage / Device, QrExec, qubes.exc while I'm currently looking at qvm-pass how to do this right. @cm157
cm157
commented
3 years ago And, I would like to add VPN (or Tor) per Qube, if not per Application per Qube, to this ticket, after disk encryption is finely done, and Ramdisk maybe ISR, was at least shortly discussed.
I'm confused. Doesn't that already exist, and how is it relevant to this issue?
I am also confused about that. Do you mean you want to design a simpler native QubesOS process for users to setup and assign a vpn config to a VM?
And what has that got to do with the $3500 bounty? Its out of scope.
valereznya
commented
3 years ago And, I would like to add VPN (or Tor) per Qube, if not per Application per Qube, to this ticket, after disk encryption is finely done, and Ramdisk maybe ISR, was at least shortly discussed.
I'm confused. Doesn't that already exist, and how is it relevant to this issue?
VMs can selectively be routed through sys-net, sys-vpn or sys-whonix, but tor browser does not even have good defaults (default Privacy settings prevent setting a Masterpassword in Password Manager even, there isn't a new Tor Identity for each new tab not even as a setting and Qubes is not supportive at all in VPNs or VPN Tunneling particular Apps or Tagged VMs (solely existing for the purpose of using Titan webmail for example) while it is not a good idea to run Gmail in the same VM for privacy reasons, if anonymity and identity by correlation matters. (Titan has a Google Analytics Pixel, and can detect a QubesOS just by Firefox Version and XFCE pretty reliably. Qubes is not masquerading the bits of information that make browser window positions / screen resolution and browser window borders leading to the assumption of XFCE ever increasingly solid with each new Google Analytics or Pixel, additional bit of information like screen resolution and processor type or behavior of 3D rendering or GPU type, even entirely invisible happening at opacity 0, while these techniques go as far as being able to tell in Javascript and CSS3/WebGL in a matter of seconds whether the browsers runs in a Virtual Machine of any type or not. Connections in distinct VMs are identifiable and correleatable, and is so far not even trying to fix anon-whonix properly making that particulary smart (and comfortable to use while at it, new Tab, new Tor identity -- it is not even providing a unique VM type for VPN-NetVM, as a Template with which one could go as far as offering a PyQt Dropdown (which already exists in Qubes Settings / Network) even for the VPN type, just asking for a config file as many Routers nowadays do.
But this is not just a layzness ćomplaint or feature suggesiton,, it addresses similiar to Compartmentalization, or Encryption of VM disks, another issue relevant to Privacy, Deanonymization and FIngerprinting. (Google Services) or Microsoft Services, Email Connections, through distinct IPSec tunnels, whereas QubesOS complements 2 browsers and a Thunderbird running compartmentalized to prevent one exploited browser bothering more than one VM or even dom0, it would be beneficial to offer QubesOS support for the prevention of Deanonymization, the abillity to group services of the same tracking and cookieless tracking origin into distinct networked exits node, and reduce the Whonix browsers support for unique fingerprnting of dominant unique finerprints of QubesOS, window positions and screen resolution, virtualization. There is an ease of detectabiliy of a compartmentalizing operating system using virtual macines. Preventing the use of QubesOS to lead to Deanonyimzation and easier Fingerprintability, simply enhancing UI/UX, and of course the original issue topic, improved VM security by encryption, would serve a similiar goal as Xen seperation of QEMU/Libvirt from the VM, and 2-3 VMs for preventing a single leak to compromize the entire system, in this case many leaks compromizing the anonymity and integrity of each other. For example for 2 different web applications, for example, Google Docs and Outlookcom (Both can be Heap Sprayed via XSS in Product, whereas a Heap Spray can lead to a Sandbox Escape or even Rowhammer, whereas Qubes would protect the rest of the system from the attacked by compartments, it doesnt, also not with disposableVMs or Whonix, shield from Google.com and Outlook.com sharing the same cookieless tracker, and Thunderbird QubeVM estabilishing a connection to Apple Mail servers and Google Mail servers. Sophisiticated tracking includes information like window position on the screen, besides Internet conneciton / IP address origin, type of connection often even being severly fingerprintable down to a device type (p0f) screen resolution, frame thickness and distance of browser windows / VMs to each other and to the frame of the screen, makes QubesOS fingerprintable.padding of browser window to screen border, and of course, IP address or type of network conneciton. Deanonymizating VMs should be taken as seriously as Compartmenalization and Encryption, and of course, as Encryption, it should be done user frinedly. @cm157 @ninavizz @rootkovska That's why this was mentioned here. https://canvastrackersimulator.org/ (EFF Link to Panoptick Deanonymizer)
And, I would like to add VPN (or Tor) per Qube, if not per Application per Qube, to this ticket, after disk encryption is finely done, and Ramdisk maybe ISR, was at least shortly discussed.
I'm confused. Doesn't that already exist, and how is it relevant to this issue?
I am also confused about that. Do you mean you want to design a simpler native QubesOS process for users to setup and assign a vpn config to a VM?
And what has that got to do with the $3500 bounty? Its out of scope.
ninavizz
commented
3 years ago I mean, this is a lot more than $3500 of work.
cm157
commented
3 years ago I mean, this is a lot more than $3500 of work.
Most of what is being discussed has nothing to do with the bounty i offered. I have no idea what is going on.
The bounty is simple per vm encryption feature consistent with QubesOS project best practices and design principles. I have no other prerequisite conditions.
Please keep it simple folks some of these posts are not making any sense.
valereznya
commented
3 years ago I mean, this is a lot more than $3500 of work.
Most of what is being discussed has nothing to do with the bounty i offered. I have no idea what is going on.
The bounty is simple per vm encryption feature consistent with QubesOS project best practices and design principles.
dom0 message passing, leading to a prompt, is pretty invasive, and I would take the load of encryption and re-encryption when a VM is idle not too lighlty, especially not when more than one window is being used. I forsee this will cause major load on the CPU, and the prompts can be an annoyance, the passphrase must be wiped, interrupting in re-encryption can mess up the file system. And integration with the OS, UI, edit of Storage/Device classes abstracting or describing LVM thin, and how to mix in cryptsetup there, wihle not doing tar of a folder and pycrypto but invoking a mechanism mainly used for full disk encryption, for a partition now, quickly, programmatically.
ninavizz
commented
3 years ago @cm157 I'm just a UX practicioner... but, my understanding of a "bounty," is that it's an incentive for community folks to find bugs that could cause harm to users. Developing a feature is a non-trivial and costly process. As it is, Qubes OS is a very under-funded project. My contributions to this conversation, and about half the time with my Qubes stuff, is all volunteer, because of this.
I'm certain that Marek and other leadership with Invisible Things Labs would be happy to consider prioritizing specific features if those requesting them paid for their development... but "a small feature" typically costs no less than a $20k to design, develop, and QA. Which I don't share as a finger-wag to your good spirited bounty offer! Just my own thoughts, as a friend of ITL and a contributor to this and other underfunded projects.
@valereznya You're not behaving on par with our Code of Conduct. You also posted an off-topic nit on some protocol, on another Issue I opened to track a different project with. Please either adhere to our code of conduct and our contributing guidelines, or leave. Critical and sometimes intense dialog is entirely possible, without disparaging others.
cm157
commented
3 years ago I mean, this is a lot more than $3500 of work.
Most of what is being discussed has nothing to do with the bounty i offered. I have no idea what is going on.
The bounty is simple per vm encryption feature consistent with QubesOS project best practices and design principles.
dom0 message passing, leading to a prompt, is pretty invasive, and I would take the load of encryption and re-encryption when a VM is idle not too lighlty, especially not when more than one window is being used. I foree this will cause major load on the CPU, and the prompts can be an annoyance, the passphrase must be wiped, interrupting in re-encryption can mess up the file system. And integration with the OS. if you want that done well, as I said, I need a new laptop, send half upfront. Thx.
I am open to the idea of providing at part of the bounty upfront and direct. You would need to be a respected member of the QubesOS development community and have the endorsements of core member of QubesOS team.
As mentioned before I am also open to providing the full bounty upfront to any core member of the QubesOS team to manage.
cm157
commented
3 years ago @cm157 I'm just a UX practicioner... but, my understanding of a "bounty," is that it's an incentive for community folks to find bugs that could cause harm to users. Developing a feature is a non-trivial and costly process. As it is, Qubes OS is a very under-funded project. My contributions to this conversation, and about half the time with my Qubes stuff, is all volunteer, because of this.
I'm certain that Marek and other leadership with Invisible Things Labs would be happy to consider prioritizing specific features if those requesting them paid for their development... but "a small feature" typically costs no less than a $20k to design, develop, and QA. Which I don't share as a finger-wag to your good spirited bounty offer! Just my own thoughts, as a friend of ITL and a contributor to this and other underfunded projects.
The semantics of what constitutes a bounty aside i do understand and agree that the value of this bounty does not reflect the true value of work necessary to implement this feature. My only hope is that someone with the time and ability to implement this and who might see personal value in its (immense) benefits could be motivated by it.
I will contact Marek and see what his thoughts are with prioritizing efforts for per vm encryption feature would be based on a non-binding donation.
Thank you
@valereznya You're not behaving on par with our Code of Conduct. You also posted an off-topic nit on some protocol, on another Issue I opened to track a different project with. Please either adhere to our code of conduct and our contributing guidelines, or leave. Critical and sometimes intense dialog is entirely possible, without disparaging others.
valereznya
commented
3 years ago @cm157 I'm just a UX practicioner... but, my understanding of a "bounty," is that it's an incentive for community folks to find bugs that could cause harm to users. Developing a feature is a non-trivial and costly process. As it is, Qubes OS is a very under-funded project. My contributions to this conversation, and about half the time with my Qubes stuff, is all volunteer, because of this.
I'm certain that Marek and other leadership with Invisible Things Labs would be happy to consider prioritizing specific features if those requesting them paid for their development... but "a small feature" typically costs no less than a $20k to design, develop, and QA. Which I don't share as a finger-wag to your good spirited bounty offer! Just my own thoughts, as a friend of ITL and a contributor to this and other underfunded projects.
@valereznya You're not behaving on par with our Code of Conduct. You also posted an off-topic nit on some protocol, on another Issue I opened to track a different project with. Please either adhere to our code of conduct and our contributing guidelines, or leave. Critical and sometimes intense dialog is entirely possible, without disparaging others.
@ninavizz whats a nit. :) i was ellaborating on other, real, weaknesses and improvements aligning with the rough scope of the thread which is "adding security" to individual or all VMs and by that reducing failure modes and weaknesses in the operating system at large, and then responded as per request and comment by @andrewdavidwong to how a particular something is related and doesnt already exist, networking rather than storage, (then there is CPU and memory, which were also already talked about), and i did so thorougly in terms of netwokring. which does make sense, sorry, and is a proven and deployed in the wild survaillance and privacy horror, which i tried to ellaborate on in the context and at use of the thread and my ability and motivation to fix things. like the encryption of dom0 controlled lvm-thin luks crypt-partions being de- and encrypted as per the device being passedthrough to the VM and that state-swift at best being incorporated into qvm-device with by calling qrc or qvm-rpc or taking the qubesadmin.VM.FeatureRequest sample to use. the $3.5k incentive to do just that in code, rather than here in text, something not particulary well thought through but definitely working theoretically and at the very least by just piping os.system commands on the shell; the sheer act of pivoting the risk of a hypervisor being able to take control over data of virtual hardware that it controls, in terms of vulnerabilities or threat models that are not being addressed and also reflect on platform compatability of Qubes at large (by the way....... @marmarek ) , because they either don't make sense to the engineer in charge at first, or do make sense to discuss and implement, but are not for other reasons perhaps the one suggesting it, and open other doors like Power9, KVM, ARM64 compatability in terms of taking ISR more serious to shield VMs on a compromized platform and at the lack of XEN or libvirt support, or as already suggested and assessed by the person wanting to fund disk encryption, RAM being encrpyted on runtime in addition to ISR, back to the thread threat model and proposed work, the threat model and benefit of encrypted disks ultimately makes sense when the passphrase is guarded by the VM once dom0 gave up control over the secret and device to another process, if said process is independently hard to crack and, since it now is a requirement for the VM process to "lock and unlock" the disk, has to guard a secret obtained by dom0, or, as suggest by @cm157 we also invoke pynitrokey, my off-topics are somewhat essential non off-topcs, and i apologize for having used deanonyimzation in per VM networking to ellaborate on the feasibility and motivation to solve and address mostly any issue, and dicusss, any Qubes related security issue, proposed patch or project, or possibility, and having the ability to implement it, but being faster when incentivized rather than looked at as if i was suggesting a cryptographically proven set of concepts on a security OS, in a github discussion. o_O @cm157
Currently volatile.img is stored unencrypted and includes swap, which means that anyone compromising dom0 or getting past full disk encryption can potentially read things that were in application memory of any VM at any point in past time, if it happened to be swapped out and the sectors were not overwritten.
This can be avoided by mounting volatile.img using DM crypt and a randomly generated key on each bootup that is then naturally destroyed on shutdown.
Likewise, not encrypting private.img means that it is not possible to securely delete a VM in a way that is fully resistant to future compromises since the data may be preserved in unused or reallocated sectors. In this case there is the additional problem of having to encrypt the keys with a master key stored in a way that can be securely deleted/changed (options could be on paper or in the TPM).
There is a performance downside due to having to encrypt the data twice (once for the volatile.img/private.img encryption, once for full disk encryption); this could theoretically be avoided, but it seems that would require major changes.